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ABSTRACT 


The needs for a medium -of -instruction programming 
language are identified, language design criteria are 
developed in the context of these needs.' A language which 
purports to meet these requirements has been specified. 

Basic structure of a motile compiler for the specified 
language is implemented using the transition matrix technique 
for syntax anatysis. 
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Olie ujD suitability of most of the important modern programming 
languages as a vehicle to teach important concepts of 'programming ' 
to those who are about to embark on making it their career> has been 
felt by teachers shouldering the responsibility. This awareness 
has become more acute with the ouergence in the recent years of 
'programming' as a major computer science discipline worsthy of 
serious academic pursuit. Ihe present project, or at least part 
of it, is a bid to respond to the above need. Its seeks to 
specify a _medium-of-^struction language for a first coirrse in the 
programming for beginaing programmers-the underlined letters 
supplying us with a name of such a language (MIPL). As we shall 
see later, the language specified is actually a small subset of 
Pl/l, at least volume-wise, and to include this information the 
langixage has been rechristened as MINIPI. 

While one part, and the original motivation, of the project 
is to come up with the specifications for, the aforesaid language, 
the other part is to experiment with its implementation. Ihat 
the implementation was going to be sxperimental was realized in 
the very beginning, keeping in view the time constraint and the 
nature and size of the team of , implementors— two M» lech, students 
■ enturing afresh into the area. 



The prinary aini v/as to explore the idea of writing a 
conpiier based upon a foraal syntax directed technique and 
meeting certain other impl mentation criteria, viz., machine 
independence, partability, etc. The choice of the particular 
syntax directed technique to be chosen was influenced by the 
availability of a constructor for generating the tables that 
drive the syntax analyzer (23). 

The present wrk is reported in the two theses subtitled 
Tart I and tart II . The contents of the two parts 

reflect, to some extent, the division of work; the common stem 
of language design and major compiler organization decision is 
indicative of the joint effort in these stages. 

In the introductory chapter we identify the user group 
and its needs, as also certain implementation requirements, 
language design criteria in the context of the user needs, are 
developed in Chapter 2. In Chapter 3> we survey certain 
prominent languages, justify the choice of a subset of I'l/l 
and come up with the specifications of MINII'L. Chapter 4 
describes the laajor design problem and decisions, in addition 
to providing an over view of the present compiler. Chapter 5 
tells about the esperience of using the transition matrix 


technique 



Chapter 6 (part l) describes the semantic analysis and 
also how the structure of a MINIIL program is checked. Chapter 6 
(part II ) deals with the lexical analysis and describes the 
associated routines. In Chapter 7 (part l) we discuss symbol 
table management, storage allocation as well as the run time 
addressing mechanism. Input/butput handling is dealt with 
in Chapter 7 (part II) which also describes the generation of 
inteimediate language output. In Chapter 8 we look back at 
the whole project in retrospect. 
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CTTBODUOmiON 

This chapter in addition to giving an int 2 x»duction to 
the changing scene of language implementation and design searves 
to outline the aim and motivation of the present project. 

Section 1.1 devotes itself to the former while 1.2 brings out the 
latter by identi^ing a group of users and their needs. In 
section 1.3 we give a few important implementation requirements. 

1.1. Languages and their Implementation ’• a brief look 

There is a fundamental rela.tienship between languages and 
the thinking habits of people. The language mirixjrs the Itiinking 
habits of those creating it, conversely, people are forced to 
think and to express themselves in the language. In particular, 
this is true for programming languages, lerhaps the influence of 
pirogranmiing languages is even stronger, as the dlalosgue involves 
not only men but machines too, and the degree of precision and 
clarity required is more pronounced. The machines have, however, 
taken laore than a fair share of the designers* attention - apl 
tlmt too got with rispfdt to the criteria in the previous 
©entice. iSarJy equijpKWt wan a palrifully pinching shoe , ani to 
push the machine to it *8 limits was Ihou^t to be all ttet was 
l^ere to proguawaing. This is ..reflecteiT:' in .ttie eariy^ hi#i leve^l 



2 


lang\iages too where optimum utilization of the critical hardware 
resources screened the poor programmers interests. With the 
fantastic developments in the hardware technology the attitude 
should have changed early enou^ “ but unfortunately it did not. 

This created a vast gap between the Bhrdware and Software 
capabilities and the computer world was faced with what J.D.Evans (lt) 
teimed as the 'Software Crisis'. In the past few years a lot of 
rethinking has been done as to what role should a programming 
language play as a tool in better programming practices. 

Ihe past decade has also seen a lot of activity in the 
area of definition and implementation of languages. Ihe roots 
of systematization of the hitherto adhoc development in the 
area can be traced to the pioneering work done by Naur et. al (22) 
in the definition of Algol 60 syntax. Ihe description tool used 
there for the first time (Backus Normal ibrm or Mi' for short) is 
not only of use in precisely defining the syntactic features of the 
language, but has also been a great impetus to the host of new 
techniques for parsing and translation of languages based on the 
MB description or it's variations. Kiese techniques known as the 
syntax directed techniques, have come a long way from Iloyd*s 
paper (ij) which described the relationship between syntax and 
programming languages and presented a top-down algcrithm for 
analysis of arbitrary context-free languages. Since- then, a lot 
of more efficient algorithms have been designed for restricted 
subsets of the context-free languages, which are important, 
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in. as much as they cover ' most aspects of the present programming 
languages. Compared to the earlier adhoc techniques, these 
syntax directed methods not only make for more efficient processors, 
in most cases they provide a central theme to give a more 
integrated and intellectually manageable compiler, ittiey make the 
extension and modification of the input language possible without 
major revision in the whole compiler. 

The present project is the beginning of an effort on 
both the fronts - language design auid implementation. Bie aim 
and motivation behind it can be more closely identified if we 
look at the needs of the would-be users and then at the additional 
requirements Imposed upon the implementation. 

1.2. The User Croup and It *3 Ueeds ; 

The group singled out as the most likely users is that 
of would-be 'programmers', or to be more specific, the beg in ning 
computer (software) science graduates (or undergraduates as the case 
may be). IQie reason wty this group has been singled out is that 
it is this group which hopefully will take up the task of bridging 
the hardware - software gap alluded to in the opening section. 

Also, it is hoped that because of the fundamental concern of this 
group with ^programming^, it may bear or be made to bear with the 
discipline stich a language might impose. The main purpose, the 
language is supposed to fulfil is as the main support language 
in a first course in programming for the beginning graduate student . 
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Now, that the identification of the users is over, let 
us take a look at their needs. It will be 'noticed that some of 
the needs were presupposed while identifying the group of users. 

This is, however, inevitable in view of the fvuadamental nature of 
the task in-volved, -vrfiere what we call as needs have been bximing 
issues of discussion for past few years. This is in contrast with 
the needs - analysis of developing a package for Civil Engineers 
or an inventory control system, where an established customer(s) 
lays out or helps in laying out needs which are more physical 
than the ones under consideration now. 

To enumerate the needs, -the language 

1. should help develop a good ‘Irogramming Style*. 

2. should serve as a vehicle for the introduction of the 
student to the important techniques in programming. 

3. should be easy to learn. 

1.2.1. Programming Style ; 

The recognition of the first need has come from the 
change in attitude towards programming. The old belief that a 
gimmick-box is the best kind of programmer that can be, has been 
fast losing groimd as the economic balance has tilted considerably 
away from the Hricby* adhoc programming and towards the 
systematic, structured pro granming. (n. WirHi (3 6), E.W.Eykstra ( 7 )). 
There has been a gradual shift of stress from making liie programs 
efficient - thou^ probably rendering it obaiure in the process - 
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towards making programs that are more readable, easily amenable 
to abstraction - hence better mangable intellectiaally , and lending 
themselves to a correctness proof with some degree of hope. As the 
complexity of programs increases the intellectual managability and 
reliability become greater problems. The need is for Ihe emergence 
of a s1yle of programming which aids the decumentation, verification 
and systematic development of large programs. Althou^ the 
language for the beginners may at times fail as the medium to 
implement huge sophisticated systems it can atleast guide the 
beginning programmer in developing such habits as will equip him 
better to meet the above mentioned tasks. 

1.2.2. Teaching about Programming : 

While programming style discussed above can, to a certain 
extent, be brought into the framework of a methodology, teaching 
programming techniques has to be tackled by exhibiting certain 
widely acceptable techniques. It is like a collection of tools, 
to master wtoose use, the tinderlying mental concepts can be 
taught only by teaching most of the important ideas that exist in 
the field. Ihe task is rendered simpler if the support language 
provides some features for natural expression of some of these 
techniques - say recursion - data aggregates list processing and 
so on. However the list tends to get longer and longer and comes 
into conflict with implementational feasibility. Besides, Ikjo many 
ready-made advanced features might lead the begimer to vdiat 
Dijkstra ( 5 ) called an» addiction* of features. In any case the 
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language should be sophisticated enou^ to make it possible to 
illustrate the important ideas. 

1.2. 3* Ease of Learning : 

A basic need a language must fulfil, especially - meant 

for beginners, is that it should be easy to learn. Ofcourse, by 

beginners we do not mean students in hi^ schools and general 

colleges for whom A.J. Perils (24) predicts continued use of 

in it, 

Eortran, as it is very-easy- to write simple programs/ Oior group 
of users is expected to be more motivated and ready to put up with 
the initial discipline. In this respect we shall consider»as a 
measure of the ease of learning, the total time required to get to 
write programs and write them well, learning about the whole thing 
in an integrated way, rather than taking up a tinkering approach. 

The baro gueness or the bulk etc . 'do come in the way and should be 
curtailed as much as possible. 

1 , 3 • Some Implementation Reqmrements : 

Die needs of the groups of users have been discussed in 
general, is to how they are to be met in the language, will be 
discussed in later chapters. The implementors also stand to 
benefit if the above needs are fulfilled in as much as it would have 
made for an experience with the ideas presented. Dae direct interest 
of this party? however, was to experiment with implementation of 
the language and the major body of the project has had to do with 
the implementation part. In addition to satisfying the above needs 
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there are some additional conditions wbich it is desirable to meet. 

One is that the implementation should be as much machine independent 
as possible —as it will help in wider availability of the language, 
once implemented. !Ebe implications of machine independence will be 
reflected in choice of languages etc. involved in the implementation 
process as also in the structure of the compiler. This will be 
discussed in detail in the chapters on implementation. Another 
requirement is that the organization of the compiler should be such 
as to permit intellectual managability and ease of extension and 
modification, both of the language as well as implementation. 

The idea of the central compact or^miization implies the minimisation 
of phases in which implementation is to be carried out. This will 
result in less book-keeping and easier management of the job, A 
centralized organization is also important as it helps in 'easier 
control. These criteria of implementation will be taken up in detail 
in chapter 4. Leter chapters will describe various individual 
implementation tasks in detail as well as the difficulties involved. 

1.4. Conclusion ^.' 

Motivation of providing a language to meet the needs of the 
beginning programmer has been established. Another motivating factor 
is the instructional value, to the Implementors, of an experiment 
with compiler writing. In the next two chapters we shall chalk out 
in detail the language we want and go on to -fcalk about implementational 
matters in later chapters. 
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liNGTJAGE RESIGl COITS3DERATIONS 


The last chapter identified the grcfup of people, to fulfil 
whose needs, it is desired to implement a new langaage. Certain 
needs were hrou^t out and in this chapter we shall attempt to 
come up with the desirable and undesirable features-in so far 
as they contribute to or violate the fulfilment of these needs - 
for the proposed langaage. 

A whole lot of opinions have been expressed as to the 
various features languages should or should not have. But a 
unified fonaal theory of language design does not exist. Most 
of the considerations are at best intuitive. The approach thus 
should be to survey and analyse the important ideas in the field 
with Ifce jtope #iat an outline emerges in the end. 

It will simplify the analysis to compartmentalize our study 
into three sections - (l) Program structure and Control Plow 
( 2 ) Data structures and their mmipulation and the functional 
capabilities and ( 5 ) the factors affecting the ease of learning » 
corresponding to the three needs, programming style, teaching of 
important programming techniques and the ease in learning. It 
should, however, be noted that such a division can not be water., 
ti^t in as much as the factors covered under one head mi^t well 
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contrilaute to the other. For example, the power to explicitly 
name and access suhfislds of a word, although an important 
contribution to the functional capability of a language, 
contributes significantly to program clarity and documentation. 
Similarly, ease of learning may he affected hy the features 
ccntri bating to the first two needs. This sometimes may pose 
an engineering trade-off and at others it may not - keeping in 
mind our definition of the ease of learning. Another engineering 
problem is that of desirability and practicability of providing 
certain features. This, to a certain extent, vjill be brou^t 
out in the present discussion but will be more completely 
discussed in later chapters when we shall specifically outline 
the omissions due to implementational difficulties* 

2.1. Program Structure and Control Flow s 

A program may he just a heap of statements or may have 
a definite structure reflecting a symmetric treatment of the 
subject. Programning style or its lack is manifested by the 
presence or absence of its various attributes - viz., readability, 
flexibility, reliability and modularity etc., althou^ data 
structures and other functional apahilities do contribute to the 
programming style-the significant effect on the features listed 
above is of control flow and structuring facilities. In this 
section we shall discuss the issues pertaining to these two. 
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2.1.1. Kie GO ID Problem s 

The only mechanisms for changing the sequential 
execution of statements in Fortran are the procedure, the do- 
loop and the unconditional and conditional jumps. Algol and 
other languages of its genre introduced certain other control 
mechanisms that occur frequently in most algorithms - notably 
the if -then -else , the while and repeat loops and the case 
statement. But most of these languages including the latest 
developed (Pascal (36)) have retained the free jump. 

Recently there has been a great controversy - the 
issue was bom with the letter from E.W. Dijkstra ( 8 ) in GiGM - 
as to whether or not the free jump ^ould be done away with. 

Tile argument against the to was that it is possible to use 
jto in many ways which obscure the logical structum of the 
progran, thus making it difficult to understand, debug and 
prove its correctness. 

2.1.2. Pi jkstra* s Basic Constructs t 

According to the Dijkstra school of thou^t four 
basic constructs are enou^ as the basic mechanisms in building 
a progran. They are i concatenation, selection from a pair, 
the precheoking ( while ) and postchecking ( repeat ) loops, and 
the * case * construct (Fig. 2,l) 


Verification strategies for proving the correctness . 
of these mechanisms using assertions regarding the states at the 
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entry and exit to these basic blocks have been given by 
Dijkstra ( 7). Althou^ the Dijkstra constiucts (the constructs 
did exist from the beginning in Algol 60, but their role in 
program verification etc,, is attributed to Dijkstra) do not 
provide any proof by themselves , they do lend themselves to 
a methodical step by step approach to proving the correctness. 

By definition (5T), a gO“to- les3 graph is susceptible to a 
sequence of transformations reducing it to a single process - 
box. Take a sequence where i (l) The correctness of the 
replaced construct has been verified, and (2) the new process- 
box contains a more macroscopic description of what the 
replaced portion does. This sequence forms both a proof as 
well as the documentation of the original programs , Taking 
the reverse approach to this bottom-up one, we can take a 
macro-box of the program description and gradually decompose 
it to finer and finer boxes till we reach the working program 
capable of interpretation by the computing environment. This 
approach to program design can better help in abstraction and 
control of progran than while using free go-to' s. 

2.1 .3 • Extensions for Sake of Haturalness a>nd Power i 

Ashcroft and Manna ( 1 ) have shown how an arbitrary 
program with go -to ' s can be converted to the one without go-to . 
The results are however not of direct interest to us, as the 
introduction of a whole lot of state variables etc., seem to make 
the resulting program even more obscure. Thus the criteria drould. 
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■fae v/hether or net programs written afresh with the iterative 
application of the aforesaid constructs can express the entirety 
of structuies in a natural v/ay. 

It has been shown hy Wulf (57) and Peterson et. al, (25) 
that there are certain graidis, to transform which, node splittings 
are required (fig. 2 . 2 a and fig. 2 . 2 h illustrate this), Phis 
implies duplication of pieces of code. For certain other type 
of graphs (fig. 2.3 is an example) Tffiilf (57) has shown the 
impotenoy of the '*node -splitting" technique. The use of 
Ashcroft and Manna type of state -variahles is suggested as one 
way out hut "Wulf himself agrees that the technique is ’odious’. 

The latter problem can however he tackled hy the use of multiple- 
level-exit loops. Wulf does it throu^ his ’escape' constmet 
allowing to escape from any of the surrounding control environments, 
Peterson (25) however proves that node splitting still remains 
essential. This anyway is not serious if the amount of code to he 
duialicated is small. If it is large, procedures can he used. 

It is here that internal procedures without paraneter transmission 
can counter to some extent the inefficiency (in time) of this 
solution. 

Higher level constructs are desirable not only for the 
sake of completeness hut also to more naturally express some of the 
frequently occurring conceptual patterns. P.B, Hauth ( 2l), 
while reviewing Dijkstra* s "Noteson Structured Programming", 
pleads in his 'open letter' to the latter that ’not all go -to’ s 
are bad' . He has given an exanple of a situation where, 



•one knows viiat he wants to do but has to translate it pains- 
takingly into .a notation that often is not well suited to the 
mental concept' . The action he wants is 'first do a j then 0 , 
then if y we are done, otherwise do 6 and we're in the same, 
situation we started' - or in a concise notaticn s 

loop a I 3 j Y then exit | 6 end loop . ( 1 ) 

The round about solution using the basic Dijkstra loops could be s 

“ 5 P Y do’ {6 I a I 3 I } I 

-1 

or 6 I repeat { fi ; a ; 3} until y 5 

-1 

where 6 is some invented trick inverse of 6 , 

Surely both the solutions do look contrived and a 
natural linguistic construct for depicting (1) is desirable. But 
the 'escape' mechanism together with a do -forever type of loop 
indeed looks sufficient to teke care of the situation. 

Bochmann ( 3 ) has suggested a new construot - 'multiple 
exits from a loop without go-to'. The format is i 

< simple loop> 


<label> 

9 

• 

■^statement > 

<label> 

« 

« 

• 

<statement> 

< label > 

• 

• 

» 

* 

<statement> 

ended 

• 

« 

<statement> 


In case of normal termination ended statement is 
executed while for abnormal exits exit loop label can be used. 
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The construct meets the claims of being easier to optimize and 
prove correct than the one using free go -to. Its addition is of 
doubtful value compared to the increase in the baroquoness of 
the language, because the effect can be achieved ^dthout much loss 
of clarity wiih multiple level exits from compound statements. 

One of the questions to be answered is whether the 
multiple level exits maintain the spirit of go -to -less programming. 
The transformationsdiscussed earlier (page 12 ) are valid if 
dotted lines (fig. 2.4) are ignored. At some stage in the reduction 
process exit lines will be totally enclosed. Hence one can apply 
the former reasoning to subgraph from which no dotted lines emnate. 
After this attention must shift to this subgraph. This may or may 
not lead to a simpler form of graph, but in either case the process 
can be iterated. In this sense desirable properties of go -to -less 
graphs are retained. Also a proof for multiple exit loop 
has been given by Clint ot. al. ( 20). 

Concluding it seems that the benefit of the exclusion of 
_go-jto,in as much as it avoids the temptation to use it as an easy 
way out even #iGn undesirable, seems to outwei^ the inconvenience 
it may sometimes cause in very special situations which arise in very 
few practical programs. Peterson et. al. ( 25 ) have themselves 
conceded that trying to progran. without has produced better 

programs and, more in^iortantly, given better insist into the 
problem than when go -to was available. 
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2.1 .4 The Stepping Loop % 

Another control-flow constrict that .has come under 
critisism from E.W. Dijkstra ( 5) is the count-con trolled~do 
or the stepping-loop. The idea of the control index uhich is 
stepped up eveiy time chains the programmer so , according to 
Dijkstra, that he overlooks the obvious and simpler solutions 
in many cases. Probably that may be the case when it is the 
only hi{^ level iteration construct available. But in presence 
of the other more general loops it seems a useful tool in the 
maiy situations where the regularly incrementing counter is 
indeed central to the iteration. Also, being a special case of 
the repeat loop, it in no way violates the proof irequirements. 

2 , 1 . 5 . Blocks, Procedures and Hierarchial Structuring : 

"Procedure is one of the few fundamaatal tools in the 
axt of programming whose mastery has a decisive influence on the 
quality of a programmer’s work" (K. Wirth (56)). 

Procedure is indeed the most important of established 
tools in a programmer’s repertoire. It serves as a device to 
abbreviate the text and more iraportmtly as a means to structure 
a. program into logically coherent closed components. In the 
process of hierarchial development described earlier, the macro- 
steps in the top-down process can be replaced by procedure calls - 
the 'procedures being defined in ihe refined versions. 
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The use of procedures, hoTOVcr, seems warranted only 
when there is a repeated use of a ' seq.uence of statements* especially 
in a language where ’compound statements* are there to do the 
joh of structuring. The blocks or the compound statements with 
declaration^ in add ition, solve the problem of locality of variables. 

The above discussion has tacitly assumed internal 
procedures. They alone are like blocks with return mechanisms. 
External procedures thou^ important for another reason described 
later, fail to provide the ease of transmission of variables 
na-turally available to the internal ones in the surrounding 
environments. The internal procedures - and equivalently blocks 
with declarations - are like service routines taking the 
throughput variables from the environment and having some local 
work areas to accomplish the transformation. 

2 . 1 .6 . Scope Rules : 

The declarations in blocks help to serve two purposes. 

One, they pr»vide a data, structuring by clearly , mentioning that 
certain data has relevance within the block only. Second, they 
help in freeing the temporary storage as soon as a particular 
block is exited. 

However as far as structuring of data goes the Algol like 
scope rules suffer from one disadvantage ( 14 ) “ hierarchial 
oidering requirep that no layer uses the data of a3X)ther layer. 

In Algol like structure this is guaranteed in one way only s 
No outer block can access data declared in the inner blocks. 
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Ooixversely, global variables are open to misase. The equivalerce 
of Fortran type of labelled comon - partitioning the data in 
a natural way - is simply not available. A solution pTOpo 
by Goos (14) is to name the blocks and preclude specific blocks 
as being outside the scope (fig. 2.5) . 


begin % except 


A j^eal X ; 


level ^ begin | 


So£pe of X 



Figure 2.5 


The storage allocation advantage of blocks depends mainly 
on dynanic allocation. "While at it we mst meation the importance 
of the static variables belonging to the particular procedures. 

Tlaeir desirability stems from the fact that at times the 
imfoimation from the past execution is important and statiovariables 
(or own in algol) are essential or at least natural in many 
situations e.g. in statistics collecting routines. 

2 . 1 ,7 . Modularity and External PTOcedures : 

One place where the external procedures seem to have an 
important advantage over the internal procedures is to serve 
better as program modules. By modules we mean units which 
can be described independently of other units and are capable 
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of being combined with others without requiring a. knowledge of a 
particular module's construction. Such routines which are usually 
kept in program libraries - impose another requirement - that of 
independent compilation. G6os (-{4) discussed the piroblem of 
independent compilation of blocks, but 

complications arise in handling non-local references (not at the 
same level external are of course simpler to handle)). Dennis (4 ) 
argues about non suit ability of internal procedures , because of 
the conflict arising, say, when two procedures referring to the 
same nonlocal y, but intending it to supiply different information. 
Dennis goes on to suggest that the only linkage between the program 
modules should be throu^ parameters. This removes the justification 
of internal procedures as modules completely. 

External procedures are also essential as a simple means to 
incorporate machine code routines once the calling conventions etc., 
are properly observed. 

2 ,2 . Data Structures - Their Manipulation and 0 the r Functional 
Capabilities 

Since the purpose of a program is to accomplish seme sort of 
computation on data, the characteri sties of a language are profoundly 
affected by the data types and data structures that it provides and 
the operations that it allows upon ihem. New languages emerge now 
and then because the existing languages do not have suitable data 
representation or methods of operating on them which may be convenient 
to use in anew problem area. 
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For a language to have a reasonable poi'ier it is necessary 
to have at least fixed point, floating point (for numerical 
compitations) , character (for text processing) and bit (for 
boolean operations) data types, dhe flexibility and elegence 
with which they can be used depends on the operations available 
on the variety of data structa3:es provided. 

For illustration, consider Fortran - it is severely limited 
in the area of text processing because of the absence of character 
data type. On the other hand Snobol would be a suitable language 
for text processing because of it’s string data types and the 
operations of matching, concatenation, substitution etc., of strings 
that it provides. Snobol is useless for numerical computations 
because it does not have integer and floating point data types and 
it's arithmetic expressions are cumbersome to form; thou^ some 
small numerical computations can be done using string variables or 
constants which are composed of digits, 

2.2,1, Structured Values i 

A number of alternatives for defining nevr data types as a 
composition of the basic data types are possible. We call values 
with such a type structured values, A structure is a tree whose 
nodes are associated with names and whose end nodes have data values. 
Structures of different complexities are possible. Some languages 
allow structures having only two levels {others place no such 
restrictions and may thereby allow structures composed of minor 
st3Xictures which may themselves be composed of further substructuree 
and so on. 



Use of stmotured data ty^ie, where aEplicahle, is undoubtedly 
an aid in increasing the readability of a program since it ijrovides 
means of referring data by meaningful names. Besides, the description 
of the structare brings out clearly the relationship between it's 
data elements at one glance. Absence of structures would force 
the prograranE r to find this relationship by looking at the use of 
different data, in program, which is a setback for easy readability. 

Of adl the languages PL/i supports the most complex structures. 
Such complex structures find their applications in business data 
processing. Becarse of their complexity they are not suitable to 
be introduced to beginners. It is felt that structures like the 
Ho are records ( 16 ) which have only two levels - one node and any 
number of components - will be more appropriate since they can be 
easily understood becaise of their simplicity and they sxe powerful aiou^ 
to be useful for most of the applications where structures are used. 

Goos (14) has made a strong argument to allow to attach 
an identifier and a data type to a subfield of a computer word 
(by that he presumably means packing within -the smallest unit, 
which may be a byte to, as character data stored in bytes are 
possible in some languages). In away this facility is allowed 
when the implementation packs boolean data one to a bit. This 
however in^jlies a uniform accessing mechaniafl determined by the 
compiler for data type boolean. As for securing a facility to 
pack differing data closely one can get it using stmctured 
Values provided the range of components is specifiable. This, 

Goos (14) says, will eliminate the need for packing and unpacking 
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data which must he described by shifts etc. Thus, it will make 
for better readability by identifying the data by its type rather 
than by looking at the operation necessary to access the data. 

The facility seems to be available in some languages vdiere raiges 
are specifiable but here too (-14 ) there is no direct control by 
the programmer over the packing majhanism . In order to avoid 
generating different codes for accessing, the iniplementation 
may decide to allign the data on certain boundaries (e.g. word, 
halfword etc.). The Hoare records however are only accessible 
indirectly throu^ jointers. This does seem to be an unnecessary 
limitation. The type of structure values given by Gries (16) 
for his example Igni^age, seems to be the best fitting to our 
nee ds . 

2.2.2. List Processing ? 

In some problem areas programming is done more naturally if 
list processing capabilities are available. Need for list 
processing facilities arises when the data structure is elaborate 
and has to be taken into account and when this structure has to be 
operated upon as well as the values contained in it. Simulations 
of ' the more intelligent* types of computation, such as proving 
geometric theoremsin Euclidean mamer, or cybemetic simulation, 
requires extensive use of lists. It is list processing techniques 
which have shown how to progran a computer so that it can, for 
example, injxit a character string such as ax + b « ox + d 
and manipulate it so that it can be output in the rearranged from 
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X = (<3.“t>) / (a-c). List processing is now inc laded as an integral 
part of some new languages liut it’s utility in numerical computations 
is very little. 

Although it is not our aim to perform sophisticated tasks 
of a specialized nature, the language should haye facility for 
basic training, so that, later, sophisticated tasks can he taken 
up in a. more sophisticated language specially suited to that task. 

Methods of construction of list structures and manipulations 
upon them very from language to language. In PL/i the use of 
pointer variables and address primitives alongwith variables, 
arrays and structures decLared BASED permits the construction of 
arbitrarily complex address linked storag'e structures. The burden 
of linking and delinking storage and the allocation and release 
of storage is put on the programmer. Other list processing 
languages, Hke SLIP have primitives for adding or deleting cells 
at the end or the beginning of the list, or between two adjacent 
cells. Primitives exist for making lists as sublists of other lists 
and for traversing the list to examine the cells and manijulate the 
data in them. 

Certain rules may exist to determine -sdien a list can 
he returned to free storage. None of the forms for the components 
of list languages has as yet been estahli died' as ’standard’ as it 
is difficult, at this stage, to specify the desirable components 
of a good list processing language. We must wait tin these 
languages have evolved into a better state. Perhaps, it may be 
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established that it is "best to hawe only the primitives essential 
for list processing so that the programmer gets full f lexihility. 

To this end, provision.of pointer variables and means to 
access and store in them seem necessary. Kiis takes away from 
the progranimer’ s hands the ejqplicit handling of links which is 
the case, say, when lists are sinulated in arnays using indices 
as links. This, while reducing chances of errors, also mates for 
better clarity in programming. With structured values providing 
a means to specify different type of cells an adequate facility 
seems to be at hand. If, we get some means of borrowing and 
returning cells to the ’free space', we indeed have a powerfnl 
yet simple list processing primitive. 

2.2.5. Recursion ; 

The wisdom of providing recursion in a, language is often 
debated because it is possible to implonent recursive oomputa-tions 
in a non-recursive way? besides, irecursion requires lots of memory 
space. In numerical work, often when the recursive definition is 
neater,' the iterative process both looks and is more satisfactory 
in use. Some people look upon recursion as an expensive luxury. 

We can think of recursion as having two main spheres of 
importance. The first is someyhat theoretical and is that 
recursive functions are the basis of the whole modem theory of 
compitable functions. The second important use of recursion 
arises because the situation in numerical woik is not. altogether 
typical. In particular, procedures for analysing structures which 
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may be recursive are most efficient if they themselves are 
recursive, and they must at least incorporate features which would 
be unnecessary in the absence of recursion in the data. Tree 
structures, which are recursive, are very often encountered in 
numerical work. Since a tree consists of subtrees any operation 
on trees is most naturally seen as a cascading of identical 
operations on sequences of subtrees. Availability of recursion in 
such situations v/ill allow the programmer to write elegant prograas 
in a natural way instead of forcing him to twist his programs to do 
the recursive computations in a non-recursive way; an excellent 
example is the tree sorting (aVL trees) program given in (52). 
isnother area where recursion fits in naturally is the evaluation 
of recursive, functions . Ackerman's functions, for example is most 
easily defined recursively and it's evaluation by other than 
recursive means is extremely cumbersome. 

Ydiether recursion should or should not be i)rovided in a 
language depends very much on what needs the language is required 
to fulfil; but there is no reason why it should not be provided 
in a language like PI/I or Algol which are based on dynamic storage 
principles and it's implementation would not require any additional 
features of significant complexity. 

2 . 2 .4 • In put/ Output s 

No language is of any practical utility without some sort 
of l/o facilities. Indeed, ISO has made a provision of explicit 
input/ output a prerequisite for recognition of a language. 
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Every programmer, including the beginnex*has to atleast 
output his reailtsj it is pointless to even write a program which 
is like a dumb giant, even worse than a mumbling idiot who takes no 
input and only outputs. The analogy is taken from Beizer ( 2 ) and 
transfixed upon program instead of computer. Therefore a beginner 
must learn l/o instructions before he has fully grasped the basic 
concepts ofthe language. Keeping this in view the set of l/o 
instructions must include some very simple instructions which will 
enable the beginner to input/output his data/ results without 
bothering too much about the layout. The formatless l/o statement 
has reason for existence primarily to cater to the needs of the 
beginner. It's popularity in the undergraduate programming courses 
is a known fact. Ofcourse, formatted l/O facilities should be 
available also, for more mature progranmers to have control over 
the layout of the grai±Lics. 

ismong the hi^er level languages l/o may be consist of 
two broad classes : stream oriented and record oriented. Stream “ 
oriented input deals wlih a continuous stieam of characters. On 
input, data items are selected one by one from the stream of 
characters that are converted to internal foim and assigned to 
variables specified in a list. Similarly, ' on output, data items 
are converted one by one to external character form and are added 
to a conceptually continuous stream of characters. Record - 
oriented input - output deals wiHi collections of data, called 
records,, and transmits -these a record at a time. Stream oriented 
input/output is conceptually easier to understand because it avoids 
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the concept of records and follows the naturo,! line of thinking 
that the next item to be input/outpat follows the previous one 
unless an explicit control is exerted to chaige this layout. 

Following the general principle of natara-lness, a language 
should be able to handle the l/o activity in a natural way. The 
most natural way to specify when and under wha,t conditions an 
l/o operation should take place is simply to command it to take 
place at the right time. The roundabout and inelegant mech mi an 
to handle l/O in languages not having comm aids is worth noticing. 

In lisp 1.5> ’pseudo functions' are evaluated for their side effects, 
such as a print operation, and their true values are ignored? in 
Snobol-, data can be output only by the awkward mechanism of 
requiring it to be a part of the special string naned SYSKlT, 

The language should be able to handle a list of variables for l/o 
in a natural way without having to resort to list procedures (as 
in Algol), without any restrictions on the n^lmber of paraneters and 
without hasring to make use of structure names, array - names, or 
names of pushdown lists artificially created for the purposes c£ l/o. 

2.2,5. Operations On Data Aggregates ; 

The influence exerted hy the set of operations present in 
a language on the programming can not be ignored. The sophisticated 
notations and operations of APL make the programs very elegent and 
concise. APL directs a programmer to organise his activities on 
arrays of data. A large set of operators are provided for 
manipulating these arrays. The variety of available operations 
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permits the p 3 X)granmier to express an amazingly large cross-section 
of useful algoritiams in a concise and natural way (24)* 

Ihe language owes it's advantages and it's difficulties 
to it' s heavy use of operators. It* s large set of operators is 
a heavy harden on the programmer. While. an experienced, professional 
programmer may love to use it for it's natural a.nd concise programming, 
it' s notational complexity makes it an impractical language for 
a beginner. Here, elegance of programs and ease of leassiing are in 
direct conflict. 

In PL/i , one can perform operations on structures, arrays 
and subaprays, ¥/hile it may be claimed that it is a convenient 
feature 'sdiich allows for succinct programs, it can not be denied 
that it is more a luxury than a necessity. How far can we go in 
providing such luxuries ? The beginner should better get down to 
do these operations element by element and lea^rti the basic fundamentals 
of programming. 

Structure and array operations do not stand condemned 
completelyi they do have their utility in special purpose tasks. It 
is fully justified to have structure operations in Cobol but it 
certainly has no place in a beginner' s language. 

2.5* factors in Ease of Learning s 

We have already discussed some of the factors which affect 
programming style in the sections dealing with block structures, data 
structures and functional capabilities. Apart from the elegance they 
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lend to the pnogran, some of the features, such as recursion, 

list processing and structured values have their utility in 
1 

a beginners langnage since they introduce some of the important 
concepts in programming . 

In this section we look at the factors affecting ease 

of learning. One of the major obstacles to ease of learning 

is too large a size of the language. Some of the modem 

languages, representatives being the two ’'Omnibus' languages 

?L/i and Algol 68, are so monstrous in size as to frighten 

away the user completely. Of course size in direct proportion 

varies with facilities provided but it is ultimately a question 

of architecture iidiere the extra features cease to contribute to 

a functional and simple design and start transforming the 

languages into what Dijkstra calls ’baroque monstrosities' . 

Yftiile agreeing that volume should be kept within managable 
limits - both mentally and mechanically, let us look at some 

of the other factors affecting ease of learning. 

2.3.1 Uniformity ; 

This term means that the same thing should be done 
in the same way whenever it occurs and that the same syntactic 
construction diould not mean different things in different things 
in different contexts. Some identifiers in PL/l, for example, 
will be treated as special words or ordinary identifiers depending 
on the contexts. It should he clear, without any elaboration, 
that uniformity is an aid towards easy learning. M example of 
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where it does not happen is the implicit declarations of Fortran 
which have been carried over to EL/i. If one intends to use 
PL/I as POR'ERfN' (yes, it can be done l) then its fine. Bat 
once we tell the beginner about the block structure and so on, he 
-iidll find by sad escperience that implicit declarations (a habit 
which he is not required to relinquish) which he thought he had 
made for an internal block, already span the whole external 
procedure -scopewise , 

2.5.2 Restrictions s 

Many languages, notably Fortran among them, impose 
irrational restrictions on the use of some of the constructs. 
Fortran allows very restricted use of expressions as array 
indices. The result of this restriction, a survey has shown 
(54), is that many-users avoid using any sorb of expression in 
the array indices because thqy find it difficult to remember the 
restrictions, Mother example, again from Fortran, is that of the 
DO-loop- index. Severe restrd.otions are put on it by not allowing 
the index to be initialized by an expression, or its final value 
to be specified by an expression. Mot only the step size cannot 
be spscified by an expression' , downward counting is simply not 
possible. 

The restrictions were placed to make the compiler design 
easier. But keeping in mind that the language is designed in the 
first plaqe for the programmer rather than the compiler v;riter, no 
new language should have no such restriotiona. 
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2.3»5» Explicit Seclaxations s 

lb 

Explicit declarations, especially whm ons is forced to 
put them in "the beginning, provide for good documentation by 
reminding one to describe them all at one place. Use of explicit 
declarations aids in detecting extrenuous data names possibly 
introduced by mis“spelling, llie fol loving example vdll illustrate 
the point. 

LBIT = LHim + 1 

Ihe intention obviously was to increment the counter by 
one but due to mis-spelling Fortran allocated two locations for 
what vms supposed to be one variable. The bug mi^t take any 
length of time to detect. By requiring explicit declarations of 
variables, such errors will be detected by Hie compiler. 

Similarly providing all ihe procedure definitions in a 
block at the beginning also makes for better comprehension. 

2 . 5 4 • Error Pixine Features ; 

Some languages have features which are difficult to master 
and even when these features are properly understood there is a 
hi^ probability of making mistakes when using them, in example 
at ha.nd is the call by name feature of Algol, The concept is 
difficult to be understood ly a beginner, and when mekinguse of 
it he can easily get himself entangled in trying to keep track of 
the different values that the formal parameter whose correspondence 
with the actual parameter is by name, may assume during the execution 



of the proceduxe . PL/I, which is based on Algol, has done well 
to exchide this feature. 

In general a language designer should shun any such 
feature the use of udiich is heavily error prone and therefore 
whose exclusion is more beneficial to the progranmer than the 
inclusion. In li^t of the discussion of 'tricky* v/s 
'methodical programming* ( 5 ) has questioned the prominence 
given to tae so called Jenkin* s Device in maay introductory 
books to Algol. 

Ihe other example ha.s to do with the syntax of a very 
improtant structured progranming construct-the 'CASEj*. 

Take the Algol W case ; 

Case I of 
begin 

A 5 
B| 

C? 

end I 

Frequent errors arise from the case construction due to the 
omission or rearrangene nt of cases. 

Steele and Sedgewick (j-j ) have incorporated a nicer case 


which goes as follows: 
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CiiSE IViffl 
2 s . 

END 

4 ' . 

# 

9 

END 

5 s . 

END 

ELSE ! . 

« 

END 

In this the case is selected depending U|?on the value of • J 

hut the possihility of the above type of error is now ■: 

almost eliminated bat for the presence of ELSE. 

I 

2.5,5" Error Messages ; 

I 

Kii s, strictly speaking, is not a feature of a language but ! 

of its implanentation,but mi^t be discussed while we are at it, | 

Good compile time error messages do go a long way to help the | 

I 

learner in the initial stages to learn about the correct structu- s 

ring of programs and proper use of the other syntactic features ; 

r 

? 

i' 

i 
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fast. Of course, extensive error checking also helps the novice 
in an indirect fashion hy saving, him from getting hogged dovnin 
solving the puzzle of where exactly the program went wrong, Eun 
time error messages fall in this category. Ihese, however, are 
best discussed in the li^t of implementation. 

2*4* Oonclusiona t 

In this chapter we outlined some of the important conside- 
rations and principles in language design, hut since a unified 
formal theory of language design does not exist, the elucidation 
of programming design principles is more of an empirical matter. 
Personal tastes and preferences vary. It is hoped that what has 
been recommended suits the needs of a large majority of programmers. 

In the next chapter we come up with the specifications for 
a language, based on the principles discussed in this section. 



GHAJ^TER 3 


SPECIFYING TBE imiIJ¥-OF>-IITSTHJGTIOH lANGUAGE . 

In the last chapter a discussion was given on 
the desirable and undesirable features in a programming language 
meant to serve as a medium of instruction for the beginning 
programmer. Based on the broad guiding principles -vdiioh evolved 
from the discussion we shall attempt to come up Tidth a language for 
use in an introductory programming course, either by designing 
a new language or, if possible, by suitably modifying an existing 
language to fit the requirements. The latter approach has several 
advantages over the former. 

Firstly, it is less time consuming; developing a new 
language from scratch is a tremendous task and time limitations 
put it beyond the scope of this project. Secondly as there are 
already too many languages and, to make it worse, they are 
proliferating at a rapid rate; it is not advisable to increase 
the existing confusion hy making an addition to 1316 Babel of 
languages. Another point against designing a new language is 
that of acceptability. To make a new language acceptable it is 
an advantage to have proper commercial and political backing 
without which it just flounders away. If a modification of a 
commercial language becomes possible we stand to gain a part of 

this advantage . Anoiiier point to considered is that people 
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axe reluctant to learn a language, however good it may he, if 
it is not widely available. Obviously a new language will not 
be widely available to start with, and it cannot be made viridely 
available Td-thout the vital commercial pudi. If a suitable 
language to ijrovide the general fomat becomes possible, the 
compatibility gained is a definite advantage and goes part of 
the way to meet the need mentioned in the previous sentence, 

3»1 • A Survey of Some Prominent Xanguages; 

In order to choose a language on which to base the design 
of our language, a survey must be made of the existing languages, 
keeping in view of our requirements of a language for novice 
programmers. Ihere is no need to consider all the languages 
because many are for special puoqposes such as those for string 
processing, list processing, simulation, for civil engineering, 
logic design, compiler writing and so on. Many others have died 
a natural death because of their uselessness. 

¥e are interested in a language suited for a general 
purpose work for the intended cammunity of users. On the forefront, 
in this category of users are Fortraa, Algol and Pl/l. ¥e shall 
compare these languages and choose the best and see whether it 
suits our needs. No attempt is made to make a detailed compaxisoni 
only those outstanding advantages or disadvantages axe considered 
which help us to conclusively discard one language or accept another. 
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3 .. 1 .1 Fortran. ; 

It is proTsalaly safe to say that, today, more compiter 
programs are rmltten in Fortran than in any other prognamning 
langaage. Because of this the use of Fortran is well entrenched. 
Programmers working in Fortran are many, and their work forms 
voluminous paorts of the progran Hhraries. Its current entrench- 
ment tends to ensure its continuing use even though this conti- 
nuofion is otherwise logically or economically indefensihUe . 

A.J. Peru 3(24) while descrihing and condoning the widespread 
use of Fortran accepts that probably Fortran is more like a weed 
than a flower - it is hardy, occasionally blooms and grows in 
every compiter. 

imong its plus points ore that it is a simple language, 
versatile and probably has the most efficient compile time and 
execution-time implementation on a majority of systems. Ihe 
oiiginal design of the language included several IM 704- depaident 
constructions which remain as seme of the weaker features of the 
language at the present time. For example the Fortran iteration 
statement i s subject to constraints based on the index register 
characteristics of the 704. It does not allow the use of 
expire ssion in count controlled statement. It's other inadequacies 
are that ft has under-developed data types and structures and 
restrictions on subscripts and expressions. 

Ihe most serious drawbacks, however axe its lack of character 
datatypes, poor decision facilities and, above all, it's poor 
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program structure. Character data is an important thing for the 
training in text-processingo Of course it can he done in Fortran 
hut in a round about and machine dependent way. Olie poor program 
structure makes it unsuitable for structured programming. Since we 
consider structured programming as the essence of good programming 
style this drawba-ck alone forces us to reject this language. Even 
if we grant that it is a simple language and easy to start off 
for the beginner, it is definitely not suitable for expressing well 
and is consequently harmful in the long run. 

3.1.2 . Algo 1 ; 

Ihe appearance of ALGOL marked a very great step forward in 

the subject of programming languages. Of the Various technolo~ 
gical contributions that it has mde in the field, the ones of 

major interest to us, are (l) a general simplicity ocmbined with 

power for stating computational process, (2) block structure and 

defining the scope of variables, and (3) recursive procedures. 

Hie first point is a genei^al one, namely that Algol is a 
clean language of great poirer for eicpressing algorithms to solve 
a wide class of problems. Hie basic purpose of Algol was to 
'describle computational processes*' and it was achieved by making 
it a problan statemoit language. 

Its block structure allows unlimited levels of nesting, 

Ihe block concept serves the the purposes of combining statements 
into groups for control purposes, of indicating the scope and range 
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of definitions for the names locally, and of defining a procedure 
which can he called from different places in the program. 3Ms 
feature makes Algol one of the languages suitable for structured 
progrrjaming. 

As we discussed in Chapter 2, recursion is one of the important 
programming concepts which we wish to introduce to the beginner, 
and this comes natural in Algol, 

Ihis discussion would imply that ALGOL would be a sin.table 
language for our purpose since it is a clean language which encoura- 
ges structured programming.and also has facilities for recursion. 

It certainly has a great edge over Fortran. It is much freer of 
restrictions and exceptions than Fortran. But as we shall see in 
the next section, PL/i is more suited for our purpose because apart 
from having these plus features of Algol it has much more. 

Input/output, one of the essential features of all programming 
languages is poorly developed in Algol. One has to go out of one’s 
way to perfom these functions. Recalling that input/output is one 
of the areas where beginnets'find greatest difficulty and that this 
is one of the first things he must leamjit is a great drawback of 
Algol as far as a beginners language is concerned. 

3 . 1 . 3 ; -SgZ : 

Pl/l is a developrnmt triggered by what people often do and 
could not easily do with Fortran, Algol and Cobol. It comhines all 
possible worthwhile features from algebraic, data processing, and 
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control languages into one unified polyglot. Pl/l offers a 
prograinmer a great amount of power and flexibility. It supports 
almost all the features of Algol (except call by name)? it has 
most of the data stiucture features of Cobol without its cumber^ 
some syntax and annoying restrictions - in. short, it is a very 
general language with the widest scope. 

One of the objectives of it’s design was to take a simple 
approach ■#iioh would permit a natural description of programs so 
that few errors could be introduced during the transcription from 
the probloa fomulation into PL/l, This simplicity arises from 
the uniform rule that each statement be terminated by a semicolon, 
thereby removing the confusion of the sort present in Algol where 
the end delimiter sometimes has a semicolon following it and sane 
times it does not. This simplicity at the statement level has been 
offset by it’s complexity due to its large size. 

PL/I is modelled on Algol, accepting all it's good features 
and rejecting it’ s error prone features (e.g. call by name and 
the sv;itcb discussed in Chapter 2). It offers all the advantages 
of Algol, is much simpler and contains sane additional programming 
concepts, PL/i , therefore, has an edge over Algol as a language for 
tho beginner if only the major drawback of its mammoth size and 
baroqueness could be taken care of, 

5«2* PL/i vs Algol : 

We will now compare Algol and Pl/l more specifically to 
hi^li^t the relative advantages and di advantages of the two. 
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PL/i has a more developed program structure than Algol. 

In Algol procedure ... end is used to delimit a procedure which . 
may then he called from several different places with different 
arguments while begin ... end are used to delimit the scope of 
names to group a set of statements for control purposes and to 
specify the duration of allocation of storage for variables. In 
Pl/l, however four syntactically different methods are used to 
accomplish the four function. In Algol by sp cifying a block to 
delimit scope of names* but not to be called cut of linGjit seems 
inefficient to be prepared to store register contents and return 
locations. PL/i avoids this by using PROCEDUEE .. . END for 
delimiting procedures and delineate the scope of names. BEGIN... 
EtJD is used for delineating the scope of names. It may also be 
used to group a set of statements for control purposes. The 
grouping of a set of statements for control purposes seems to be 
a much simpler and common structure than one in which the scope of 
names is delimited. Further, it seems confusing to define a 
sequence of statemaats delimited by begin and end as syntactically 
different due to the accidental declaration of a single local 
variable. Therefore in PL/I DO and END are provided fox grouping 
purposea". As far as specification of the duration of allocation of 
storage is concerned the artificial correspondence between the scope 
of nanes and storage allocation in Algol is rejected hy Pl/l in 
favour of allowing the prrogrammer to specify the appropriate 
attribute for storage allocation. 
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PL/i has a mch broaier and flexible l/o facility than 
Algol. Unlike Algol in which l/O is done in a xound about way 
l/o in PL/i is very natural and simple. Of special interest 
to us is it’s simple stream oriented format free l/o particularly 
suitable for the novice. 

Keeping in mind the difficulties caused by the call by 
name feature of Algol the designers of PL/i have studiously 
restricted it. Apart from this call by name feature Pl/l 
encompasses almost all the Algol features. In PL/I only simple 
variables are called by name. 

Ihe data aggregates of Pl/l are much more developed than 
those of Algol. Ihe concepts of data structures and cross-section 
of arrays are completly missing in Algol. 

The list-processing capabilities provided by Pl/l by_ the 
use of it' s pointer variaJble, oonirolled storage allocation aid 
da,ta structures are also absent in Algol. 

Althou^ it has no significance for a beginners language, 
for the sake of ocmpleteness we mention that PL/i has several 
advanced features such as multi-tasking, compile time facilities 
and control over storage allocation, which are not found in Algol, 

Ihe introduction of such a variety of facilities in PL/i 
has not been achieved without paying a price for it - it has 
become a language of gigantic proportions ; the size of it's 
manual alone intimidates the beginner. Although one would desire 
that a user could ignore some of it' s syntactic and semantic details 
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unrelated to, his application, experience (24) has Aoto. that 
the side effects which can arise do not pemit this very often. 

It' s otherwise free-from-error-prone usage is marred hy it* s 
complexity due to size. Many people have criticised it for it* s 
hulk. To quote twos 

t 

1 . The language itself as well as it* s description have assumed 
remarkable dimensions and PL/I seems to be ill suited as a 
basic introduction to programming because of it* s sheer size 
and it*s lack of a systematic structure with a unifying 
underlying conception' - N. ^irth ( 36 ). 

2, Ph/l, a programming language for -vhioh the defining 
document is of a fri^tening size and complexity. Using 
PL/i must be lil© flying a plane with JOGO buttons, switches 
and hsaidles to manipulate in the oockjjit * - E.W, ])ijkstra( 5 )» 

5 « 3 '‘ The Required Language- a Subset of Pli/l s 

It is clear that PIj/^» it's totality, is a large complex 

language unsuitable as a beginner's language, althou,^ it's basic 

constructs and program structure are simple for comprehension by a 

laixguage 

beginner. Therefore, to make it acceptable as a beginner's/ its size 
must be out down drastically, retaining all the desirable features 
and none which is not going to be used by the beginner and whose 
presence may cause unnecessary difficulties for him. 

A subset of PL/i chosen on these lines will have numerous 
advantages over the full PL/l. Namely s 
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1. Hie programmer will not have to remember those features which 
he is not going to use hut the ignorance of -viiioh may give 
erroneous results, 

2. Pall PL/i requires a large system for implementation, A 
subset of it can be easily implemented on smaller machines 
and made available in all computer centres instead of only 
in the large ones. If, qlnicomputers come in vogue, as is 
being predicted, PL/i may soon become obsolate^ only it* s 
smaller versions may survive. 

5. A smaller subset is easier to implement and has more efficient 
compilation. 

In sifting the subset out of PL/I we must have some guide 
lines for it. The guidelines are very general and not very tech- 
nical in nature I they are set more by commonsonse then by any fomal 
principle. 

In chosing the subset we must obviously include the basic 
essential features such as the assignmoat statement, express, ons etc, 
without which it would be meaningless. 

It must include those constmots which help meeting the needs 
of the intended community of users. These have been discu®ed in 
Chapter 2 where some empirical considerations in language design 
were given. 

Some features, such as the compile time computation, multi'* tasking, 
the mo 3® complex l/O mechanisms etc., which are irrelevant to our goals 
are to be rejected outright. Those features, which may although be 



desirable, but have only marginal utility may be excbided to 
restrict the compiler to a manageable size. 

Certain error-prone features, like mixed expressions, 
should be excluded. 

In choosing the subset care must be taken to keep it a 
pure subset of PL/i. Parity is desired so that the beginner 
can si?itch to Pl/l painlessly and so that programs written 
ill the subset can be run on a machine where PL/i is available. 

Ihe title of the thesis only supplied four letters for 
the name of our language MEDHJM-OI'-IIIS'MJCIION PROGRJMILW 
L/lIGUiGE. Now the justification for inclusion of the other 
two letters N and I making it MINIPL - the language is really 
a minature PL/I, at least in volume if not in substance. 

5«4* Ihe Language MINI PL - Specifications s 

Describing the MINIPL fully is a big task and will 
acquire the proportions of a moderate sized manual. Away out 
of this problem is to describe it by comparison with PL/i, 
pointing out those features of the parent language which have 
heen excluded and sometimes those which have been included, 
depmding on which one is more economical spacewise. Of course 
this method of description assumes a fairly good introduction 
to PL/I . A q,uick -check syntax diagram is however provided in 
Appendix A .1 which will help settle disjutes, if one arises. 

Ihe description will also incorporate the reasons for 
inclusion (or exclusion) of the features wherever necessary. 
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[Ehe semantics associated T^ith MIHIPL constructs are the same as 
those for PL/i except where the restrictions have been explicitly ■ 
mentioned. 

Not all the features of ICENIPL have been implemented. The 
extent of implementation will be brought out in later chapters. 
Nliat we describe here is the set of features -sdiich it is desirable 
to imrjlanent. 

The following features of P.L/i which are advanced and not 
necessary for the beginner have been excluded in accordance with 
the guidelines set earlier, 

1. Idilti -tasking and a,ll it's associated data types and 
operation s, 

2. All compile time facilities. 

3. Exception condition handling and program check-out, 

4. Generic names and references. 

5. Editing and string handling. 

6. Record oriented transmission. 

7. Passing arguments to the main procedure. 

The following features are excluded to keep the Imguage 
manageably small for implementation. Their utility for a 
beginner oannot be entirely ruled out but since our main goal is 
to provide facilities to encourage good programming habits and 
to teach the important programming concepts, and not, to give 
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each and every -these fea-fcures can he left out. 

1. Punc-fcion procedures. 

2. liXT&y expressions and struc-fcure operation. It is 
felt that the beginner will get a better feel for 
programining if he does these things by himself, 
elonent by element. 

3. Dynamic aitrays - -they req.'uire a more complex storage 

allocation and therefore have been excluded, 

4. 13ae general mixed expressions of Vh/l are not allo-v 5 ed 
because they are very prone to errors and are doubt- 
ful in aid to program clarity. It is described in 
greater detail -when expressions are explained. 

5. The use of GO TO statement has been restricted to 
improve the program structure. It can be used only 
for exiting from the control envir'^nment . Free jumps 
all over the place are prohibited to maintain the 
neat structure of GO-TO-less programming. 

In the following pages we discuss the major features of 

% 

MINIPL which include the program struc-ture, data types and data 
struc-tures,- statements, expressions and program elements. 

5 *4 • 1 • Program .S.truc.ture : 

Statments of MINIPL can be organised into blocks to fom 
a program. Co'n-trol- may be passed within a program from one 
block of statements to another. 
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The structuring of a program into blocks serves the 
purposes of 

1, Delimiting or defining a procedure which could be called 
from different places in a program with different arguments, 

2. Indicating the scope and range of definitions for the names 
locally. 

5. Combining of statemoats into groups for control purposes. 

The structuring is done by procedure blocks, begin blocks 
and do groups. The ability to stmcture a program in this 
fa.sMon gives a major support for doing structured programming. 

The rules for forming the blocks using the program structure 
sto-temcaats (i.e. PEOCEIUEE statement, BEGIN stelement, END state- 
ment and AIjLOCATE and PEEE statemaats) are the same as in Pi/l. 

The exception being that the END statement may not be followed by 
a l^el constant -the documentation can be done by putting /* 
label */. The declare statements must come in the beginning of a 
block just after the internal procedures. This rule is imposed 
for better program I^out and programming discipline. Having data 
descriptions in the beginning improves the readability of the 
program. It also mate s implementation easier and more efficient 
because it ensures that all the attributes of the variable are 
available to the conpiler before usage. Prom similar considera- 
tions of implementation ease, program laycut and programning 
discipline the internal procedures have to come ri^t in the 

beginning of procedure block in which it is nested. 
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Some examples of blocks j 

Procedure block 

A . . PBDCEIiUBE (x,Y, z),. . 
B.. PEDCEDUEE. 

m 

EKD ■ /* B */» • 
DBCliEE X EIXBD, . . . 

END /* A */, . 

Begin block 

BEGIN , . 

DECLARE St^itement 


EHD /* CDX */,. 

Begin. Block Termination s A BBGIH block is terminated when any 
of the following occurs. 

(1) Control reaches the EHD statement of the block. 

(2) The execution of a GO TO statement within the block 
transfers control to the EHD statement for the 
current block or for the block in which it is nested. 

(3) A STOP statement is executed. 

(4) Control reaches a EEITJHH statement that transfers control 
out of the begin block and out of it* s containing 
procedure as well. 
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Pr ocecluxe Termination ; 

A procedure is terminated itien one of the follomng occurs; 

(1) Control reaches a ESTCJEN statement within the procedure, 

Ihe execution of a EEKJEN statement causes control to he 
return. ed to the point of invocation in the invoking 
procedure. 

(2) Control reaches the EtlD statement of the procedure. It 
may happen during the sequential execution of the program 
or hy the use of a GO TO statement. 

(3) The execution of a GO TO statement within the procedure 
(or any block activated from that procedure) transfers 
conbrol to a point not contained witMn the procedure. 

If the transfer point i s contained in a block that did | 

I 

not directly activate the block being terminated, all [ 

intervening blocks in the activation sequence are terminated, | 


Examples 

* 

CALL A I • 

» 

A. . EROGBDUEE , . 

B. . PROCEUJEE, . 

GO TO 

# 

* 

» 

END /* B Vj • 
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C.. PEOCBDUiSl, . 

» 

a 

CALL B, . 

« 

« 

« 

12ID /* C V, . 

CALL C , . 

AS o . El® /* A */y • 

In this example assume that procedure A is active and 
it activates procedure G, C activates B. In B, th.e exeution 
of the statement GO TO AS terminates procedures B,0 and A. 

Stora/?e Allocation s There are three storage classes - static, 
jtutomatic and Based. Static allocation is done if it is desired 
that the value of the variable he preserved upon exit from a 
block. All variables that have the STATIC attribute are 
allocated storage before the execution of the program begins, 

A variable that has the ALTCMiiTIC attribute is allocated 
storage upon activation of the block in Tdiioh that variable is 
declared^ it is freed when the block is freed. There is no 
provision for an explicit declaration to give AUTOMiffilG attribute. 
Any variable which has not been explicitly declared as STATIC 
or BASEL is given the iUTOMATEC attribute by default, with the 
exception that any variable that has the EXTERNAL attribute is 
assumed to have the STATIC attribute. 

The BASED storage class has been provided for Ust-prooe- 
ssing. The details of its use are to be found in section 5 . 4 . 4 . 
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Recursion ; in active procedure can be reactivated from 
ivithin itself or from within another active procedure. Suoh 
a procedizre, called recursive prccedui^e, must have the EBCTJE 
option specified in it*s procedure statement. Ihe effect 
achieved by recursion in MIHIPL is the same as in PL/i. 

Phe facility for recursion has been provided. to give 
the beginner an introduction to programming concepts in 
accordance with the decision taken in Chapter 2 . 

Su.br outines s A subroutine is a procedure that is invoked by a 
CiiiL statement and usually requires arguments to be passed to 
it, Wien a subroutine is invoked, a relationship is establi.shed 
between the forma-l and actual parameters; the type of the two 
nfust match otherwise it would give erroneous results. 

Functions and System functions s Bie functions have not been 
provided because they are difficult to implement; the system 
functions, however, can he incorporated #ien the need arises. 

System functions can he regarded to be operators belonging to 
a class of their own. 

5.4.2 Data Elements ; 

The data types in ffiHIPL may be divided into two catogoxies- 
pi?oblem data and program control data. The problem data is used 
to represent values to be used in processing. It consists of 
arithmetic, character string or boolean data types. The arithmetic 
data has a scale- either fixed or float. In MIHIPL a variable 
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declared to Ise of fixed -point scale is taken to Toe of arithmetic 
dafa. type of binary base and a floating-point declaration 
gives it the decimal base. The arithmetic data constants are 
a.11 decimal. The fixed-point case i s similar to Fortran where 
the arithmetic data constants ai^ decima-1 but have a binary 
internal representation. 

The programmer is not given ary control ever the specifi- 
cation cf the precision in ihe declare statement. The precision is 
equivalent to the default option of PL/i and is set by the 
compiler and depends on the implementation. 

The character string data has been restricted to length 
one for all purposes except when used in a PUT statement to 
output a string constant. This exception has been made to give 
the user facility scanewhat equivalent to the outputting of the 
hollerith string in the FORTEiU format statement. For all other 
}pu.rpo®s the character string data can be considered to be 
character data since it has unit length. The character data has 
been provided for text processing. 

The bit data type is the Pl/l bit string of unit length. 

It has been provided for boolean computations. 

An example of declaring the data types of variables is 
given belows 

DECLABE A FIXED, B FLOAT, C CHAR, D BIT, E POINTER 5 

The POINIER variable is used to point to a location. The 
value of a pointer is an address of a location in storage. The pointer 
data is inc lided to do list processing. 
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5.4.3‘ Bata Agffceffates s 

In MMIPL the important data aggregates have been 
included, namelys arrays and structures althou^ they are not 
of the same complexity as in EL/I . 

in: rays s Ihere are no dynamic arrays in MIMPL. Olie reason 
for their exclusion has already appeared in 5*4 • Bhe value of 
the lower and upper hounds of the dimensions may he selected 
hy the programmer. For the sake of uniformity hoth the hounds 
must he specified in a BECLifflE statement instead of taking the 
value of the lov/er hound to he one hy defailt as is usually done 
in most of the languages. 

im. example of declaration of an array; 

BECLASE X(--20.. 4 O) EIXBB ,. 

Bata Structures ; The basic facility to define structures ■ 
values as outlined in chapter 2 corresponds well with the Pl/l 
if we limit the levels of structure to 2 . Thus at level 1 we 
give the name of the structured value and level 2 the components, 
A typical declaration will he. 

BECLiEE 1 STHJC ( 5 ) , 

2 lETIBR ( 10 ) CHiR, 

2 ' AGE FIXED, 

2 PORT POINTER, . 

This declares an array of length 5 called STHDC - each of whose 
components is a structured value of the type 
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If means to declare ranges of numbers etc. were ay£3ilabl6 
(to a certain extent it is possible in ?L/I but has been 
excluded because of implement at ion al oaaplexity), then we shall 
have the ability to access subfields of a word (by that, we 
mean fields that we get vftien packing chars in floating point and 
fixed point number cells). PL/i does provide varying ranges for 
integers but even PL/i(f) which is a fairly big compiler puts 
integers in only two forms half ward and full word. MINIPL does 
not include range specification facilities, presently. 

Reference to a oomponait of structured value is to be 
explicitly qualified in MINIPL,that is, structured variable take 
the following foms; A.B. , Q(5). P » S(5). T(3) » tf«(5)» 

Subscripts must immediately follow the identifier, unlike PL/I, 
where, S. T(5) is permissible. 

Pointer Variables j We discussed in Chapter 2 the necessity 
to icrovide pointer variables. Cries (16) gives two functions for 
pointer variables meaning of which is clear from the exaaple below. 

P = iEPRESS (a) (i) 

B = CONTENTS(P) (2) 

CONMTS(P) = B (5) 

where, A,B are say fixed point variables and P, Q pointer 


variables. 
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(1) sets the pointer to point to A. 

(2) stores the contents of the cell pointed to hy P in B. 

Thus the effect of (1) and (2) is the same as B = A. 

PL/I declaration for pointer is, 

DECL^fflE (P,Q) pointer 

PL/i provides exact eq.uivalent of (1) which is ADDE.. 

As for B there is no direct equivalent and one has to use the 
lDa.sed variables. Now we have to declare, 

DECIilBE ACCESSOR PIXEB BASED (XXXXX), . 

where in normal PL/i XXXXX i s a pointer associated with BASED 
variable ACCESSOR. We shall not have occasion to use it as 
we shall only be using ACCESSOR to access values pointed to by 
other pointers say P and Q. The equivalent of GONTENTSCp) will be, 

P ACCESSOR 

or in MINIPL P PT ACCESSOR 

5 4 *4 “ last Processing t 

Structure variables with pointers as components give a very 
poYierfdl means of providing list processing priiaitives. The 
facility of Cries' language (16) when CONTENTS (P) becomes 
synohlmous to structure name B if P is pointing to B is simply 
not possible. 



58 


■Hae equivalent of CONlOTrs (P). will have to make use 
of a hased structure. It will be done as follows : 

mcum 1 ACC basep (xxxx) 

2 R . .. 

2 S 

2 T ... 

P PT ACC . S 

MIL 5 In addition to addresses a pointer variable may be 
assigned WILL, which means a quantity which is no address at 
all. 

Pointers can be tested for equali'ty among themselves as well 
as against BUIL. 

Q3ae major advantage over the SUP like languages is the 
possibility to have cells with different sizes and layouts. 

Cries (16) has not proposed any methods of getting or returning 
cells, a facility of crucial importance if full benefits of 
list processing are to accrue. The facility beoomesvery simply 
possible if we can provide the based storage. The suitable 
formats seem to be 

allocate a 5 

vdiere A is a based structure declared as 

DECLARE 1 A BASED (XXX), . 

2 . . . 

2 ... 


2 


« • * 
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The address of newly allocated cell will be pit in XXX * 

Hiis cell can now be linked in the list being used by assign- 
ing the value of XXX to some pointer variable in list. 
Similarly using 

PliEE FJITT PT A, . 

will free the cell being pointed to by PONT the cell size 
?;ill be determined by the size of A. That is, if one 
ALIOCATBS A and FEEES B (same pointer qualifier) it is his 
own funeral. 

The features may be included in MINIPL if the special 
storage allocation (discussed in chapter no. 7 (Part l)) 
becomes feasible. The format for freeing and allocating will 
be as discussed above. 

5*4*5* Statements s 

A ffiNIPL program is constructed from basic program 
elements cabled statements. There are two tjrpes of statements •* 
simple and compound. These statements make up larger program 
elements called groups and blocks. 

A simple statement can be a null statement. 

G.g. of simple statements 

A = B + C , , 

GO TO START, . 

A compound statement is a statement that contains one or 
more other statements as a part of it's statement body. There 
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is only one compound statement- the IF statement. The 
final statement of a compound statement is a simple 
statement that is terminated "by a semicolon. Hence, the 
compound statement is terminated hy this semicolon. 

e.g. IP A GT B THEN A « B + 0 , . 

ELSE GO TO R, . 

Unlike PL/I only the END statement may be labelled in MINIFL, 
so that the GO TO can be used only for exiting from a control 
environment. This has been done to enforce GO-TO-less 
programming. 

The statements can be grouped into the following 
classes; 

1. Descripjtive statement . 

2. Program struotare statements. 

5. Data movement and computational statements. 

4. Control statements. 

5. Input/outpat statements. 

D G scri ptive St atement ; The declare statement constitutes 
this class . A declare statement can come only in the 
beginning of a block. There are two types of Declare statements; 

^ , Declare Statement for structured variahles ; One statement 
of this type can describe one structure only. This restriction 
is imposed for clarity In reading and implementation ease. 
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DECLiHE ■■ 1 JACK, 


2 AGE EijqnD, 

2 W-GHT PIXEID, 

2 HEIGHT FLOAT, 

2 ADDRESS -(1:10) CHAR, 
2 MARiEIBD BIT | 


ITote that the stractare consists of a major structure 
nnTiie and sever al elements. There are no minor structures. 


2. Dec la-re statement for non-structured variaLless In this 
statement da,ta types and storage classes may he attributed to a 
vcirLahle or an array. All the attributes of a simple variable 
or array must be given at one lolace only. %is improves 
roadability. 

The precision of arithmetic variables is not to be 
specified becaase they are al’.vays given a standard precision 
by default. Absence of the EXTERNAL attribute implies the 
IN'jEPdM'isL at'bribute. Elements having the sarae attributes may 
be factored together for convenience. The declaration of an 
array must include both the hounds. 

o.g. 1. DECLARE A FIXED, B FLOAT, HOURS (l0:40) 

FIXED EXOERNfiL, NMES STATIC CHAR, 

STilTUS BIT, (ATR, MATR( 1 s 10))PIXED § 
e,g.2. DECLiRE A FIXED, B FLOAT, ASTATIC; 

This is invalid hecouse all the attributes of A are 'not 
specified together at one place. 
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So ope rales 5 Ihe scope rules for the declarations are the 
some £'.s those of PL/I. 

iittri hates s The declare statement is used for describing 
structures aoid for assigning attributes to variables ond 
structure elements. Isa attribute may assign a storage class 
or data typo or range to a variable. 

A check list of 3.11 the possible a,t tributes which can 
be used in a declare statement is given below; 

Storinge class Attributes ; BASED, STATIC 

Data Type Attributes s FIXED, FDOAT, GHiR, BIT, POIRIER 

Range Attribute s EXTEMAL. 

Tlie default o'ptions in the three ca,ses are AUTOMATIC, none and 
lUTA lALiL re spec tive ly . 

C ontrol Statements ; The GO TO statement is for unconditional 
branching? the destination is specified by a label constent. 

Tlie unconditional branching is restricted so that one may branch 
only to labelled ERD statement -vdiich terminates the block or 
group to which the GO TO statement is internal. 

Tliis is consistent v/ith the GO -TO -less programming concept. 
The, GO TO is provided only for the purpose of exiting from a block 
or a. group. 

Examples of usage of GO TO statement, 

1. BEGIN? 

9 

IP A NE B THEN GO TO XLT? 

* 

XET s END? 

The branch to XET will terminate th,e BEGIN block. 
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DO 5 

DO J = 1 TO 10 I 

• • 

GO TO TEEimiiTS 5 

» 

Ei;n)5 

TETJ-ffijiiTE s EHD | 

The iteration ends if the jnsip is made to TESMENATB, 

5. For an example of termination of active procedure hy the 
use of a GO TO statement refer to the termination of 
procedures in section 3-4 ‘I* 

T he IF statement s The IF statement is identical to the Dijkstra 
construct for selection from a, pair, discussed in Chapter 2. 

They ere reproduced helov)- for convenience. The IF statement is 
one of the important constructs which is an raid towards a good 
program stmeture. 

The IF statement construction is as follows s 

IF <'bool.expr .> TEEN XI | ELSE X2 5 

where <hool.expr.> is a condition i.e. boolean expression* 

X1> and -X2' can be either a statement, group or 
begin block. 

The ELSE clause is optional. The syntax rules for forming 
an IF statement and for .nesting are the same as in Pl/l , The 
meaning of the IF statement becomes clear from the diagrams given 


below. 




'if him else' ST ilEEMMT 'iF THEll' STilEEMEI^T 

Hie SO statements s The common uses of the DO statement are 
to specify that a group of statements is to he eiaecuted 
iterrtively under count control or as long as a given condition 
holds true, or it may he used to delineate a group of statements 
for control purposes,. Consequently there are three DO statements 
for each of these three functions. 

i. Count controlled DO statement % It has the following syntax. 

DO <variahle> = <initial valae> TO 
<final valued BY <step> 5 

or DO <v'ariahle> => < initial value> To <final value > | 

The < initial value >■■ , <final value > and the < step >. are 
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restricted to either constcaits or vexiablas. 

Ihe 30 statement egn be used in the same as in PL/I,- 

this 

ITote that v/e can do av/ay "vvi thy type of DO statement and manage 
'vTith a DO TJHILE statement (described belov?)| but since count 
controlled iterations are so common it has been provided as a 
convenience . 

An example of use of a count controlled DO statonsat: 

DO J = 1 TO 10,. 

* 

* 

END, . 

The sta.tements between DO and END mil be executed 10 times- 
unless the loop is terminated prematurely by a GO TO statement . 

2. DO V-HILE statement s It has the following syntax and can 

ho used ixa the same way as in PL/i. 

DO MILE <h. exp> where, <h.exp> is a boolean 

expre ssion . 

'Oae DO YffilLE statement provides us with Dijkstra''s |)re- 
ohocking loop construct shown below. 



’do while' ST i'iTEMElNT 
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Ezcaaple of a SO MULE statement 5 

DO MlliS ,X GT 10 ; 

MiD 

Uie statements b etween ' th e DO and END -will be executed 
as long as X is greater than IO. 

3. Non-iterative DO statement s It is simply the statement >D0, .• 

This DO statement, in conjunction with a DO group is used 
to indicate the DO group is to be treated logically as a single 
sto/tement. It has onother very important function to perfona 
ill conjunction with the GO TO statement- that of providing means 
to terminate the execution of a count controlled DO group or a DO 
'■.HILE group without completing the iterations. This can be done 
by nesting the iterative DO group within a non-iterative DO group, 
Yhen the iteration is to be terminated it can be done by an 
unconditional jump to the END statement which corresponds to the non- 
itercvtive DO group. See subsection on' GO TO statement' for an 
example. 

The DO statements can be used exactly as in DD/I ; keeping 
in mind the restricted nature of their syntax in IIINIPL. The rules 
for nesting of DO groups in PL/I are valid in MPNIPL also. 

The count -controlled and the DO MILE statements of HINIPL 
ca'.mot be combined into one statement as in PL/i. The combination is 
rarely used and therefore has not been provided. 
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I /'c statements ; Only streaa oriented l/o has been pacovided 
for it's simplicity. Even in this class the da.ta“d.irected 

l/o has not been provided because it's utility is questionable 

and it is so different from the other modes of l/O that the 

beginner ^^ill have difficulty to switch from the data-directed 

I/O. 

To keep the l/o statements as simple as possible the FILE 
option has been excluded because the beginner 7d.ll only be 
conoGmed fdth the standard input and output files. The repetitive 
option, too, has been excluded 5 and, since the repetitive option 
is eiDoluded there is not much point in having array input and 
output. It does not reduce the l/O capabilities. The repetitive 
option can be done by the use of a DO loop. 

The format has been simplified by allowing only integer 
constant for specifications o.f field widths and counts. The 
Ie 8 f 3 often used LIIIE, and COLOUIvlir control .format items have been 
eliminated. Only insnediate formats are allowed -it aids in 
better readability than the remote format. 

Although MINIPL has no character string data, the output 
statement .can spiecify a character string constant in the output 
list. To avoid conceptual confusion, since character string 
data is not there in MIIIIPL, we shall call it message- string 
instead of character string. The message string has been provided 
to serve, th.e same purpose as the hollerith fields in Fortran 
formats. Although the same effect could have been achieved by 
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■usini;; the charsaster data - only it wcfuld be very cumbersome. 

Hio message string is output in the same way as a character 
string is output in ?L/i . 

Some typical l/O statements are given below: 

GST HST (X, A.B, C(e)) 

iITT TAGS hTST ( 'OUTHJT I S = ' , B), . 

KIT SHF (5 ) BEST (A*B + 6, 6.3 - 4*y), . 

(331 SUIT (A,B,C) (e(i0^3),X(5),P(6), SEIF(3), A(i)) 

HIT Vim EBIT (TaOBUCT IS ' = ' , A * B, ’ SEEK IS = *, A + B) 

(2 ( A(1), X(2), F(4))). 

Bata movement and computational statement s 

Internal data movement involves the assignment of the 
value of an expression to a specified variable . The expression 
mry be a constant or a variable or it maybe an expression -ydiich speci- 
fies that comiutation is to be made. The assignment statement is 
uoGd for internal data movement as well as for specifying 
computation. The general form of the assigment statement is s- 

Yariable = an expression , . 

The expression is evaluated and assigned to the variable. 

Tlae value of the expression will be converted to match the data 
type of the variable. The convgrsion rules are the same as those 
of IB/I. 

3 .4 *6 . Expressions : 

?L/i has very generalized expressions. Mixed mode expressions 
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are allc?rad to the extent ths,t a hoolean variahle msgr he 
iTiLilti plied hy a decimal variahle or a relational expression 
may he ovsiluated and added v/ith aaothor relations,! expression. 
‘Ztiis involves conversion of data types from one typie to another 
according to fixed rules. ¥Jhile forming the expression the 
programmer hss to keep track of the data type of the result 
after each application of an operator. This is very prone to 
errors a,nd there is a possibility that the programmer may 
unintentionally mix the data types in an expression which will 
he difficult to dehug. For the sake of clarity MimPl disallows 
mixed exjpressions altogether? consequently there are three 
catogori OS of expressions- namely iiritlrjmetic, Helational and 
Boclcrji expression. 

iiTitlmietic expressions are formed in the usual way hy using the 
operators + - * / ** and tlie jparanthesis, Tariahles and 

const mts used as operands must he of decimal data type» litLxed 
arithmetic expressions involving floating point and fixed point 
d2,ta. is not allowed. A simple variable or constant of decimal 
d-ata type can also he considered to he an arithmetic expression. 
The vfilue of an expression is 'of the same base as the operands. 

Bo lati on al expre s si on .A relational expression may he formed 

hy 

(1) Using any relational operator on two arithmetic expressions, 

e.g. ■ A'+ B GT G/B is a relational expression. 

(2) By using the operators = or 'ne' on character variables or 


constants 
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e.g. Z NE 'G' is a relational expression 
'.There Z is a character variable. 

By using the operator ’ = ’ or 'Iffi'on Boolean and relational 
ccqiresaions. If a relational expression is used as an 
operand it mst be paranthesised. 


e.g. 1 A AND B 
(hool.oxp) 


C OR B 
(hool.exp. ) 


is a relational 
expre s si on * 


e.g. 2. A isNB B = (C LT d) 

(hool.exp) (relational expression) 

iorenthesisa.tion is necessary to reicove aaihiguity. 
e.g. A = B NEC C 


(where A,B and G are Boolean va>riahles ) 
can he interpreted as (A =» b) IIE G 

and also A = (B EE C) 


Boolean exioression s A Boolean expression can Be formed By using 
tho Boolean operators on Boolean expressions and relational 
c7:prGsslons . A Boolean variaBle or constant is also considered to 
Be a Boolean expression, ^iie order of evaluation is from loft to 
right with'EOlf having the highest precedence and 'or' having the 
lowest iTCCcedence. ijeiational operators have lower priority than 
Boole-on operators. c,g» of boolean expressions! 

1. A OR B 

2. A OR EOT B 

3. A OR B iED C 


4 . 


A ACffi X GT I 
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5.4.7 o !I!he Basic Elements of MIHIPl 

MliUPL uses the 48 .character-set. Ihis implies that 

manj'' of the operators and delimiters will have to he represented 

hj a combination of characters, 

5g. ’>* is represented by ’ G'T' 

t .» is represented by ' , . ' 

Ihe representation of the semicolon causes some problems. 
Consider the statement HIT UST (ii, . 5)1 
Comina followe.d by the arithmetic constant ,3 leads to the 
formation of a semicolon. f!he user has to be careful to leave 
a. blinic between ‘iiie comma and the period in such situations. 
Identifiers s The syntactic mles for creating an identifier 
are the same as in Fortran. The maxLmum length of an identifier, 
ho V, 'ever, mgy be larger than six and depends on the implementation, 
imy tv/o identifiers in a MIhIPL program must be ' separated by 
at lo.ast one blank or some other delimiter. 

lie served Words : Many identifiers are reserved and may not be 
used for any purpose other than the one for which it is intended. 

A list of reserved words appears in Appendix A . 3 . 

TTse of Blanks s Blanlcs may appear anywhere in the ICEHIPL program 
as Icng as they are not contained in .identifiers, constants 
(except character string constants) and composite opere.tors. 
Comments s Comments are permitted wherever blanks axe allowed in 
a program, (except in character string constants). The general 
format of a comment is . 

/* oharaoter~st3ri.ng */ 
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In the last few p.3ges a description of MINIPL has heen giTen Tery 
briefly.’ Since it is not possible give a full description 
in such a small space there are bound to be some omissions. 

In case of doubt, the final arbitrator is the grammer given 
in Aprendi xi., -I for syntax, and the PL/i manual (19) for 

the corzesponding semantics. 

3.5* « Conclusions % 

In this chapter we have come up with the specifications 
of a, language based on the language design principles 
oxpourHed in Chapter 2. Not every one Tdll agree with the 
decisions taken because of variations of opinion. Because 
of look of any formal or OLuantitative methods of testing only 
time end usage can shew how good a language MINI PL is for the 
bcfdii-ner. 



CHAPTER 4 


BQ?IPMaHJATIOH ; PESiaiT CCMSIDBRATIONS MD OVERVIEW 

Starting from a statement of needs and thr^ju^ a 

discussion of language design considerations in the contezt of 
these needs, we came up with the specification of the language 
MINIPP towards the end of last chapter. How onwards, we shall 
concentrate on what approach we have taken in designing certain 
major parts of the compiler for this language. 

In the piresent chapter, after looking at the translation 
process in general in section 4.1, we discuss the choice of the 
technique for translation in section 4.2. Section 4.3 disoribes 
the various languages involved in the translation process. In 
section 4.4 we discuss the choice of .the number of passes and in 
section 4.5 various aspects of m/c . independence. Through these 
sections we indicate the major design decisions. In section 4.6 
we discuss the implementation of these decisions in terms of 
present implementation. The last subsection 4.6 gives a description 
of the overall organization of the compiler and points to where the 
details of individtial tasks and associated routines are to be found, 
y/e close with a discussion of how to incorpoi?ate the compiler into 
the operating systoa. 




Symbol 

table 


Intema! 

of 

Source ] 



-> 


Constant 

tabl&(s) 




Other tables 


Flow of information 
Flow of oontrolo 


Fig. 4. 1 
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4.1. The Compilation Irocess : 

k compiler basicallj perfoims aa analysis of the source 
program and then a synthesis of the object progi-am. Ib get a 
general idea of the process fig. 4.1 may be helpful. Ihe figure 
is just for illustration to show the basic tasks involved; the 
distribution of work is quite often not so rigidly fixed as 
indicated by the boxes. Bae flow of infomatiori lines may also 
not be what they are indicated in the figure. 

Primarily, the lexical analyser takes in the characters 
of the source program and builds the valid symbols of the program. 

It does blank squeezing and may do comment deletion. Many times 
it produces it’s output in a fixed length internal code, making 
the task of the rest of the compiler simpler by letting it operate 
on fixed length code rather than the variable strings of characters. 

Syntax and semantic analysers disassemble the source program 
into it’s constituent parts, building the internal form of the 
program and putting information into the symbol table and other 
tables. A complete syntax and semantic check of the program is also 
performed. 

The last phase corresponds to the actual translation of • 
the Internal source program into the machine language. Some times 
a code-generation preparation box is added before the last one. 

Certain tasks are specifically sealed in this box - namely rm-time 
storage allocation to variables, and some optimization on internal form 


produce better code. 


76 


Having got the general idea, it must be noted that the 
above is a sketchy description of the logical connection of various 
tasks. The different tasks can be performed one after the other 
or in a perfectly parallel interlocked fashion. Setween the two 
ends, other organizations also emerge. Similarly the tables and 
the information kept may very much depend upon the language and 
the objectives of implementation. Many times the details of 
information which it is required to maintain may be cone clear 
through the implementation only. 

We shall now discuss the choice of the basic, strategy for 
oirr implementation especially . in view of the requirement laid down 
at the end of chapter one. 

4.2 Syntax Directed or Otherwise : 

Various techniques have been used for translating 
programming languages, imong these are statement categorization, 
keyword recognition or template matching, syntax direction and 
table direction. Till early sixties, most of the compilers for high level 
languages were of the brute-force categorizing a new statement by 
a type; then, by a rather complicated process emitting code that 
represents ■ the semantics or meaning of the source statements. 

These compilers sufferred from the lack of a central underlying 
. concept and tended t^o be disharmonious collection of routines 
joined together in an ad hoc fashion. With the development in 
the theory of languages there emerged a fomal notation of specifying 
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the rules of well formed sentence construction (syntax) and the 
methods that use this description to recognize and parse the 
sentences of the language. These methods of translation tend 
to be independent of the particular language to be implemented 
as they use a 'tabular' representation of 'syntax' or the rules 
of forming the sentences of the language. This separation of the 
description of structure and analysis algorithm is in contrast with 
ad hoc -techniques where the structure is in an indirect fashion 
incorporated in the parser itself. This makes the modification 
of the input language simple as not much change is required in the 
parsing algorithm proper. Also the algorithm provides a central 
underlying concept which coordinates the whole translation process 
in a natural way. Once the parse is through or while parsing, 
'semantics' or the meaning of syntactical entit’leB may be 
determined. This corresponds to the production of machine code 
corresponding to high level language constructs. This latter 
process, however, is mostly carried out by specific algorithms 
embodying most of the information about language semantics. 

Recently efforts have been made to describe semantics also in a 
formal machine-independent notation but few, if any, practical 
compiles based upon these have been implemented. Nevertheless, 
the central syntax directed technique does make the task of 
introduction of semantics easy and uniform. 



78 


The choice thus obviously is that of a syntax directed 
technique* A recent effort (18) attempted a compiler of Fl/l on 7044 
using the statement categorization process. Syntax analysis 
in the PL 7044 (18) is a decentralized process and is carried out 
by several statement decoding routines. This strategy j, it is 
claimed j has the clear advantage of being fast when compared to 
a centralized syntactic analysing scheme. The advantage is said 
to accrue from the fact that each decoding routine not only checks 
the syntax but also assigns the semantic interpretation simultaneously, 
a possibility which is precluded in the case of centralized scheme. 

This conclusion, however, does not seem to be well founded. The 
reason of simultaneity seems to have nothing to do with a centralized 
technique. As we shall see, the semantic analysis can be (and is 
in the present implementation )done hand**in-hand with the recognition 
of individual syntactic entities and there certainly is no repetitive 
checking performed, as suggested. The ad hoc checks which are 
inevitable in the type of analysis in (l8 )not only do harm to the 
program clarity but also contribute to repetitive coding which is a 
disadvantage, as conceded by the implementors also (18). Bie 
statement categorization type of syntax check requires lot more 
documentation than what is needed with a central technique (hardly 
any , except for the syntax description and the basic algorithm). 

We must however confess that our choice was in a great measure 
facilitated by the presence of a constructor ( 23 ) to automatically 



79 


build tables directing the syntax analysis process. 

4 . 3 . languages involved in the Process : 

The source language-let us call it of course MINIPI. 

fne ultimate target language 1 into which this is to be translated 
is the m/c language of the computer on which MIKIPL is to be 
implemented. The intermediate languages can be denoted as 
^1 ^2 ‘ ’ ^t 1 ’ call the three languages invol-ved in 

implementing MIKIPl , Ij , P and L| to bring out their relationship 
betteri The whole translator may be regarded as a transformation 
from to L^. We may write, 

1 ( 1 ^)^!,^ ( 1 ) 

The relationship between the various phases of translator 
is throu^ the intermediate languages and tables of information 
they output and accept. 

In particular the language Lj will be very close to 
(a coded representation in fact). The language P will be the 
main intermediate language chosen to be the Gries Quadruples ("16), 
in the present case. We may have a further language L? as the 
assembly language of target computer, (though this is not 
considered an efficient solution). 

Now the mapping T can be considered as a combination of 
four submappings, T , t, T_ , T, . The process may now be represented 

S J id p 

as a sequence of transformations ; 
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T (is)-*- I' 

* H 

and (L^) -> 

evidently is the lexical analyser, the syntax and 

semantic analyser and code generator, is a conventional 

assembler, the need for which may or may not be there depending on 

the level of the intermediate language l. . 

1 

4.4. Choice of the Nimber of lasses : 

the number of passes in a compiler, we mean phases v\^ich 
produce intermediate output in core or on output units. The 
successive phases are either overlaid on the previous ones and use 
the information in core, or are loaded as separate programs which 
read the input form the input devices. The choice of number of 
passes is dependent upon many factors, ainong them ; The core size. 
How fast the compiler should be ? How fast should the object 
program be ? How much debugging facilities should the object 
program have ? 

In general, if a lot of optimization is desired, the core 
size limitation will dictate that the number of passes be greater. 

On the other hand fewer the. number of passes, the lesser the quantum 
of I/O activity, in general, and to that extent the compilation is 
faster. Sometimes the sheer size or the nature of source language 
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itself makes it imperative that more passes be employed. 

In the present case it was decided to make the compiler 
essentially one pass, not counting the intermediate-language (l^) - 
processor which will be discussed soon. The reasons to justify 
the choice were : 

a. In the kind of environment envisaged (of beginning 
'programming f students) fast compilation is more important 
than hi^ly optimized code. 

b. The present language MDIIPL is a heavily reduced version 
of Pl/l and as such the size problem is considerably less 
acute . 

c. One reason that makesa one pass compilation impossible, 
i.c.use of variable before they are declared, does not 

hold in case of MIHTPL because of the requirement of explicit 
declaration for all variables in the beginning of a block. 

The other problom (is) of not knowing any ting about the 
foimal parameters of a procedure is alleviated by the 
following features of MINIPL. .The declarations will 
immediately folow the procedure heading. Also labels or 
procedure names can not be the argumaats of a procedure. 

That still leaves forward references of go-tos and calls 
(essential because of recursion) but these can be taken 
care of and the method is described when handling of labels 
is discussed in chapter 7 (Payt l). 


I 
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d. Larger nimber of passes imply a larger number of 

interfaces, in the present situation for a closely knit 
team of two^ it seemed more advantageous to have a single 
pass rendering the contiol simpler. 

4.5. Machine Independence : 

a machine independent implementation -we could ideally 
mean a compiler that can be used on ary machine v/ithout modification. 
Such a definition is indeed preposterous, especially for a program 
like a compiler whose task is to map the source language (h^) 
the machine language (l^) of the machine. However, it is obvious 
that most of the logic of the compiler including syntax analysis and 
building of syntax trees is essentially independent of the target 
language L^. She reasons why it has not been possible, in many cases, 
to avoid the waste associated with repetitive coding of the 
aforementioned logic, are : 

a. Ihis logic is inextricably mixed with that of producing 
object code to make the reuse of coding nearly impossible. 

The advantage claimed by Gupta et. al. (I8 ) of fastness 
accuring by, assigning semantic interpretation (target 
language, L,^, oriented) is a hurdle in achieving machine 
independence. 

b. The choice of the medium of» writing the compiler has been 
the assembly language of the computer on which implementation 
is being carried out. This feature, main reason for which 
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is the efficiency of execution time for compiler, 
makes the computer immobile « 

YIe discuss next how to get around the above two obskcles 
to machine independence especially in the context of present 
iniplementation. The solutions also solve some other problems which 
will also be indicated* 

4*5.1. The Language : 

An obvious method to separate the machiiie independent 
portion from the machine dependent one^ logicwise^ is to separate 
the work in two phases# The first one produce b it^s output in 
some intermediate language (l^) and the next pha.se processing this* 
Thus the compiler could be implemented, assuming that the language 
in which it is v/ritten can be executed on the compiler - how this 
done will be described in the next section, on different machines 

shown in fig* 4.2. 
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The main question to be answered is j what should be the 

level of detail in the language L. . It could be quite hi^ level 

level 

incorporating the control constructs of the hig^ languages or it 
could contain simpler and more elementary control flow mechanisms. 

The type conversion operations could be incorporated here or this could 
be done later. In general, higher the level^ probably more 
independent the phase I processor will be. Ifowever too high a 
level for the language will just be transfering the problem to 
this level. In the present implementation it was decided to 
do most of the processing in phase -I processor, here on referred 
to as the 'compiler',, so that the intermediate language processor is 
simple enough to be implemented with a minimal effort. It is this 
decision that justifies calling the present compiler one pass. The 
second pass is - as will be seen shortly - equivalent to the 
conventional assembly where, the output of the compiler which is in 
the assembly language, is assembled. 

4.5.2. Making the Compiler Available on different Ifachines : Bortability 

Even when the machine independent logic is separate from 
the machine dependent one, to make the compiler usable on different 
machities it is essential that the language in which we have written 
the body of two compiler is available or can be easily made available 
on a given computer. The approach taken in the present implementation 

is (fig. 4.3) : 


Implement at ion on M' 


I.L.P., 



I.X, 

Code 




(x) Implementing: L on M. 


Hotr-tion s i Compiler for L written in the language s. 

I.L.gS Prooossor for intermediate language written in the 
language s. 

Pg % Jirhitrary programs written in the language s. 

M & M* ; Machine language interpreter for machine language • M & M* 
(These could he the machine thaaselves) . 

Fig. 4.5 
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Take a language L' which is available on machine M'. 

Write the compiler for L in L*. This compiler C^, generates the 
interaediate language code. As soon as we have written the 
intermediate language processor, we have the language L implemented 
on M' (fig. 4.3a). The main aim however is to make available Ii on a 
machine M which may not have the language L’ available on it. We 
proceed as follo?;s(fig. 4.3b) : 

Code the compiler for L in L itself. Uow using the compiler 
C^, (written in L') translate tirie new compiler 0^. We have a 
compiler C written in the intermediate langimge. This compiler 
can be implemented on any machine as we assumed that I.L. is 
implementable on any machine vifithout difficulty. Thus we have the 
compiler for L written in the machine language of machine M. 

The version of compiler written in L can be effectively- 
used for main-fcainance, that is improvement and additions. The new 
compiler in intezmediate language can now be obtained by using the 

old running version of compiler to translate 0 . 

L 

4.6, Present Implementation : 

Having talked of the -two major requirements and their 
influence we shall now give the important design decisions while 
describing the present implementation. Pointers to where the 
details are to be found in next chapters will also be given in this 
section. First we describe the intermediate language chosen, then 
consider -the. language(s) for the coding of compiler and their 
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limitations with respect to machine independence. This will be 
followed by a brief description of the overall control flov/ in 
the translator. In this last subsection we shall also talk about 
how the compiler could fit into the operating system. 

4.6.1. Quadruples ; 

The intemediate output from the compiler in the present 
implementation consists of Gries Quadruples (l6 ). Itimarily these 
have the fom ; 

operator, operand 1, operand 2, operand 3 
where, ^operator' is the binary operator operating upon operand 1 
and 2 and storing the result in operand 5 » This form fits in naturally 
in most arithmatic and similar operations where the operands are 
locations. Ibr other opexation^hese could be labels or procedure 
names etc . Many Quadruples may have fewer operands than the number 
shown. A list of Quadruples can be found, in Appendix 0 , 

This is by no means complete as new quadruples may be specified to 
take care of a specific situation as semantic interpretation of more 
and more syntactical entities is incorporated. 

An important thing that should be pointed out is that the 
level of our intermediate language is quite comparable to an 
assembly language and thus their processing should not be very much 
more difficult. In fact, in line with the philosophy of doing the 
maximim amount of work in the compiler phase (section 4.5. 1) making 
implementation of Quadruple Processor simple, it has been decided to do 
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the storage allocation in the compiler itself. Also most of the 
table maintainance is already done to minimize repetition in 
Quadruple Trocessor. Storage allocation and table management are 
discussed in chapter 7 and how the Quadruple Processor can be made 
simple using these features is also discussed there. 

Some Advantages : 

Ihe operands in general are locations and thus action of 
an operand is to produce a result in a location. The interaction 
in Quadruples is strictly through locations. This is in contrast 
to triples (op, operand 1, operand 2) (l6) where the result is 
assumed to be associated with the triple itself. This makes the 
interdependence between triples strong and their movement to 
facilitate code optimization more difficult. The detailed discussion 
may be found in chapter 11 (16). Another advantage of quadruples 
is that all operands being locations, no reference is made to any 
registers, accumulators etc ., features which are dependent upon the 
architectiire of the individual machine. This makes the generation of 
quadruples easier, thou^ a lot of temporaries get allocated in 
the process. The operands depend very much on the addressing scheme 

■V, 

and for the block structured langixages they may be collections of 
subfields indicating block count, offset, type, indirect addressing 
etc. The operands may be labels too. Exact details of these are 
given in chapter 7 while discussing the addressing scheme. The 
quadruple format may be varied to sviit different possible implementations 
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of Quadruple Processor. So this end, a separate Quadruple generating 
routine is written which be nodifed to produce different 
formats. Details of this are given in Chapter 7(Part II ). 

4.6. 2. Ihe Coding language : 

Main body of the compiler has been written in, IDREblD 
(corresponding to the language of section 4«5.2). Erom the 
criteria of readability as well as the ease of coding this was 
more suited than MAI, the assembly language of the machine M* (iM 7044). 
Some of the routines requiring packing, unpacking and shifting etc., 
have been coded in MAP. The interface is well defined between MAI 
and POETRAU and hence does not pose much problem. Also it is possible 
that the Quadruple processor may require information in the reverse 
order from the one in vrfiich it was generated by the compiler. This 
may include header information available only at tne end of compilation 
of an external procedure. An easy access to such information is 
possible if a sufficiently large number of secondary storage 
files are available. POETRAN meets this need to a certain extent. 

The language, L’, (pbrtran here) -is however not of much 
significance as far as machine independence is concerned, since 
after the initial implementation on M* it is discarded in favour 
of MINIID. Thus the question becomes whether the above mentioned 
tasks can be performed in it. The problem of packing and lonpacking 
can not be tackled in the present MIKIID. If variable ranges for 
integer variables are added it might become possible-# Another thing 
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that MIBItL lacks is file handling. Y/e have in MINIPI, only one 
input file and one output file. At the minimum we need an output 
file for source listing and one for quadruples. !I!hus MINIFIi* s 
ability to control secondary storage has to come from the machine 
language routines j written for each new machine M. This is what 
makes the MliTIPL compiler less than portable. However, identifying 
the machine dependent routines and writing them as external procedures, 
v/ill alleviate the problem to some extent. 

Although PI/I does have a full complement of file handling 
capabilities etc., these were not included as this would have made the 
implementation complex and the compiler impossibly large. Moreover, 
file handling did not come within the perview of MIHIPL whose main 
intent is to serve as a medium-of-instruction language, and not 
necessarily as a systems programming language. 

4.6.3. Organization of *the Compiler : 

fig. 4.4 gives the flow of control and information in the 
MINIPL compiler at a very -very macro level. The term ^compiler’ 
as pointed out earlier will be used to refer to the phase I of the 
implementation which produces as it*s output, the intermediate 
language code( Quadruples). Phase II which is to produce the final 
machine code from Cmdruples is to be referred to as Quad-ruple 
Processor. The desirable features of it to some extent will be 
outlined in gbapter 7 . In this section after looking at the 
'compiler' we shall also talk about processing of quadruples on 
IBM 7044 while describing the possible O.S. interface. 
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Quadraples and other information 
for the quadmple processor 

Indicates the- diieotion of control transfer (procedure 

invocation) 

Indicates the direction of information flow. 

(TEE OTERAIi ORGmZiiTION OF GdlPIIES) 


ELg. 44 
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The Flow of Control : 

I’ig. 4.4 shows that control is first passed to the main 
driving routine MORIV. This is the routine which is to interface 
with the O.S. Ibr the present let us assume that only one job 
(or a series of job's, delimited by a $) is there on the input and 
quadruple modules for individual external procedures ai'e to be 
outputted on the secondary storage. AHDEIV recognizes the main 
procedure heading and passes control to syntax analyzer. Syntax 
analyzer routine MIZE now retains control until the end of the job 
is signalled by a $ when it returns control to MIRIV which after 
completing the end-of-job formalities, if any, looks for the rna-in 
procedure of the next job. MIZE obtains lexical units from the 
lexical routine (iTXTITM). performs the task of searching reserved word, 
tables, building constant tables etc., in addition to forming of other 
atoms of MINIPl. MLZE calls the main semantic routine SHHM, where 
a checking of program structure is made and semantics corresponding 
to different syntactical entities carried out. ^mbol table 
maintainance and storage allocation are also done here. Semantic 
information is associated with the syntax tree partly by the MLZR 
(this is the information supplied by the lexical, e.g. types, pointers 
to constant tables etc.) and partly by SIMM. The quadruple generating 
routine OUTQil is called from various places in STSME to generate 
quadruples corresponding to syntactic entities. EEEOB routine is a 
centralized error messaging routine called with appropriate eraror code 
to print a specific message and take corrective action, if any. 
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Details oi syntax analyser and program structure checking are 
given in ciiapter 6 Cl’art l), and of the lexical analyser and 
associated routines in chapter 6 (Part II). Other semantic routines 
are described in chapters 7 of the two theses (Part I and II). 

Storage allocation addressing and symbol tables are described in 

chapter 7 (Birt l) and iutput output, and quadruple generation 
ixi Chapter 7 (Part II ). 

Operating Systeai Interface : 

The compiler as implemented and discussed above is only 
one link, althou^ the most voluminous and complex, in the process 
of getting a MINIPL job run. To complete the process following things 
are required. The header information (for external linkages) and 
the quadruples are to be collected from the two secondary storage 
units and the information put on a third file, for every external 
procedure. The routine to do this must be called by the main driving 
routine. The output may be collected and then fed as data to 
quadruple processor which puts out the binary object program on 
another file. Quadruple processor returns control to the system 
which loads the object program in core and transfers control to it. 

A simple method to utilize the present operating system processor 
facilities on IBfl 7044 is to delegate most of the quadruple processhig 
work to the MAP assembler. The scheme envisages considering 
quadruples as MAP MACHOS and writing macro definitions to generate 
code. Oontrnl can be passed to the MAP assembler by switching the 
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system input file to the unit on which quadruples were generated. 

One big disadvantage is that all the macrodefinitions (for all 
quadruple-types) have to be included in every itibP routine corresponding 
to an external procedure since there is no provision for defining 
system macros. Secondly IvlAP assembler is avdcward for the present task 
as it can not miike use of the storage allocation in MINIPL compiler 
phase. But the most important thing against this mode of implementation 
is it’s slowness. A routine containing the three run tine storage 
allocation macros, one macro for fixed point addition and five or 
six uses of the latter took almost a minute to assemble (Appendix e). 



CHjU^TBR 5 


.;K?AHSI'PI0N Mrax TBCI HNIQ UE 

'Wv; . .(‘tliotl. n oX ’based upon syntax, come under the 

group oi‘ dlrnofcd tochniquos. Floyd (13) distinguishes 

hotwoon vvlird, lu; onllM thi; ' Byntax diruoted analysis’ and 'syntax 
controlled .'Uii'-lyoo;.;' , By the foimcr ho means use of analysers 
vrorking on rK-hiu direct reprcaentation of the syntax, while in the 
latter clacii the nii.alyscr is driven 'by some tables wbioh axe 
derived fro!;i thu syntax. Tho general top-down analyser described 
by Ploy'd (15) cunc'S in the former category. This and similar 
algoritlmu .involvo back-up and while they accept a wider class of 
langaag(-*o (B'loyd's algorithm is form arbitrary CPi), they tend 
to bo incfi'iolont. Recent modifications hav^e improved this drawback 
to a corttdn extent (9 ), but so far most compilers have used 
algorithna that parso more restricted (howe^feoj general enou^ to 
inoludo most jarsiotical programming languagss), class of Imguages, 
more offioiuntly. Most of these teohnilues are bottom up teohniquesj 
and nood no brnk-up. The paper on translator-writing-systems by 
Peldmon md Grios (12) contains a comparative study of several such 
techniques vdth respoot to the following criteria ; 

( a) How much, space does the recognizer use ? 

(b) How fast is the recognizer ? 
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(c) How nmch does a ccKnyentiojaal granmer have to be 

in' oid-Bi "to Id© accsp'tsd ty tii© oons'tnio'toi;? 

(a) Onoo the recognizer is constracted, how easy is it 
to ijasGrt semantics and the syntactic properties hy 
the grammer ? 

The results are generally Sn conclusive and definitely do 
not provide enough information which can make the choice automatic. 
One of the tochniques discussed by Feldman and Gries (12) uses 
Transition Matrices. The technique is said to he the fastest as 
it eliminates the need to search productions every time a 
reduction is to he made. The main drawback cited is the large 
amount of space used hy the switching tables and associated 
suhroutinos. The technique, in essence, was first introduced hy 
Samelson md Baiex (50). Gries (15 ) later formalized the technique, 
made some variations and presented an algorithm which constructed 
from a suitable BNF grammer, a left-right recognizer. Patil (25) 
in a recent wojic implemented the constructor. Availability of 
this constructor was the major determining factor in the choice 
of the transition matrix technique, for syntax analysis in the 
present implementation. 

During the process of writing the syntax of ihe present 
language to suit the technique certain interesting things emerged. 
These were mostly related to modifications necessary to meet the 
conditions on the input grsratier. 
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Cdbain VECci. aiiioiis 'wbtq made in ■fciie con stmc 1501 ? ou'fcpu.'t in 
the interests of storage economy while maintaining the speed. This 
and some other variations are described in the present chapter. 

The main objective of the present chapter is to tell about the 
experience -^slth the transition matrix technique. But before we 
can taHc about these details, a description of the technique and 
the recognition process in short is essential. Greater details 
and formal proofs can be seen in (15). 

5*1 The inint grammer : 

The input grammer is restricted to be an operator grammer, 
i.e., in no production should two non -terminals occur in adjacent 
positions on the_R.H,S. ' This by itself does not impose any serious 
limitation but some breaking up and alteration is required, an idea 
of which may be gathered by looking at the operator grammer for 
MIMIPL given in ippendix A, 2 . 

Tlio following io an example to illustrate the situation s 

cdool non strc> <deol non stro <type> 

<typ 0 > fixed / PIOAT 

This is not permissible because of the O.G. restriction. The 
problem csom bo tackled by making ’type' a lexioal output unit 
TYIE. However, if previously <type> had included the case, 
<typG> <initial list> 

<initial list> INITIAL ( . . . 

TO las in wfiibh iist> figures 
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thenjINITIiOj will have to he taken as a TIBS and <decl non stro> 
would pe_:oolate into all the statements where <initial list> has 
been used. Tho problem in the present case was solved by putting 
the condition that initialization can only come after all the 
attributes of the variables are specified. IThus allowing s 

<deol non strc> •+-<decl non strc> [TYEE ^initial list> 
The operator grammer is coded into numbers according to the 
scheme igiven in Appendix A. 2 . The constructor reduces the number 

of symbols in the ri^t hand side of a production to three. Oliis 
simplifies the recognizer and allows- a direct correspondance to be 
set up between states of transition matrix and certain non -terminals 
of grammor. The change does not essentially alter the structure of 
the parent O.G. but consists of inserting intermediate productions . 
For example, 


will transform into, 


and than into, 


<a 

expr> ->■ 

<a expx> + 

<term> 


<a 

expr> 

<a expr - •+ 

* 

> <teim > 

\ 

} 

f 

f 

<a 

expr - + 

expr> 

+ 


<a 

expr > ■+ 

<a expr - + 

~ term 

i 

f 

r 

<a 

expr - + 

- term *> ■$ a 

expr - + * x<fcerm> 

E 

I 

<a 

expr - + 

* > -»■ <a expr > + 

r 


The newly introduced symbols axe called Starred Won Terminals (SWTs) 
and are distlnguiahed from the original TJnstarred Won Temmals (UWT»s) 


I 
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-by an asterisk. The new granmer is called the iugumented Operator 
Grammer (aog)* 

By applying a sequence of mles ( 15 ) on the OG - the iDG is 
constructed systematically. The AOG has only the productioisof the 
form, 

-»■ TT2 , -V IJ* , U* 

IJ* T , TS* BT, U# -v B* B^*T, B* B* BT 

5 .2 Bniquo Parsing of an AOG ; 

Grios (15) has proved that if an iOG is unambiguous, so is 
the p,aront OG from -which it was derived. The sufficiency conditions for 
an AOG to ho unamhigious are listed below: 

Condition 1 .. 

* 

For oach pair B^, , T^ where B^-*^ is a SNT and T^ a terminal, 
at most one of -the following is true, 


3 

j 

a production B -»• B^ such that ^ ^ J 

L(^,) 

(1.1) 

3 

a production B* -+• T^ 


(1.2) 

3 

a .production B + T^ sudi that B^ e 


(1.3) 


where , (x) is tho left set of the symbol X, i.e., the set of symbols 

which occur, in some sentential form, adjacent and to the left of X . 
Furthermore, if (1.1) holds, there is only one such BBT B(SBTs B* in 
(1.2) and (1,3) are unique by construction}. 

Conditior!^ 2 s For oaoh triple B^ , B^, T^ -sdiere B^ is an SNTs, B^ a 
BBT, and T. a tomiaal,at most one of the following is true: 

tj 
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3 

a x)roduction IF Uj^, where, U e Xy(T-) aid 



either or \ | 

(2.1} 

3 

a production II* -+• U^* T^, Tshere, or 



*IF^ 

(2.2) 

3 

a production U* -+■ where, U^* e^(U*) and 



cither Uj^ = IJ^ or Uj^ ^ 

(2.3) 


Farthexraoi’o, if (2.l) holds, "both U and.Uj^ are unique while if 

(2.2) or (2.5) holds , is unique. 

If conditions 1 and 2 hold, a unique parse of the iDG is 
possible. 

Tho Constructor Outixlt and the Parsing Process • 

'fho constructor checks for all pairs which of the three (I.1), 

(1.2) find (1.5) holds, and records the L.H.S. of the reduction and 

tho subroixtino which reduces the prime phrase . Similarly, 

for triples, conditions (2.1), (2.2) and (2.5) are checked. If 
more than one condition holds, or the derivations fromU's are non- 
uniquo- oorrosiJonding messages ate printed. 

Sho original Gries (15) scheme records the outpit in the 
form of a two dimensional transition matriuqwith rows 00 3n:e spending 
to SNls and column e to terminals. Ihe scheme makes use of a pish 
down stack to hold the OTs and a single location KL to hold the 
non -terminal IF ^ (fig. 5 *l)‘ 
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^3 ‘ 


Fig. 5.1 

At ;,ny .'jtagG the incoming texmtnal T. and U.*(top of stank) 

0 * 

axe used to find a suhroatine from the transition matrix. 

This suhrou'bine, ioossihly throng a series of if statements, checks 

if the is apxropriate. If the process fails either in finding a 

subroutine in transitional matidx or while examining lJ^,the incoming 

symbol T. in in error and the statement is rejected. The process is 
J 

started by intting is stack (j)* corresponding to the terminal <ji 
which is asaxmod to bo appended to the left of all sentences. 


ITL 


TJ. 


Stack 




u/ 


U2^ 

u* 

3 

4 * 

h 


5*5 The Throe Dimonoional Output Matrix s 

The entries in the Gries matrix are sparse (around 800 
in a matrix of approximately 65 x 5^ » fo^ present implementa- 
tion). Patil (23) devised a packing schaae in which each entry is 
in the following foamat (each entry is a 70^4 (f^t) word) s 


Bits 3 6 6 6 15 .^- 5 - ^ 


.WX UQ ^ 

w 

NE 

I 

J 

DSB * 

i 


: 0 i 

' 

J 1 

i. IfSB 1 


IIE 5 No. of entries in row I 5 I s Bow no. (code for some TJ*) 

J s Colxuiin no. (code for a terminal); HSB : Dumber of the group o 

statements (oorresp. 
Fig. 5.2 routine 
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S©3icchijis consists of looking for positlyG HE* SjCliocking s and 
jumping acoTosa the KE number of entries in case a failure occurs 
The scheme was modified to a catalogue type (fig. 5.3) in the 



Nov/ the need for searching for U*'s is completely eliminated 
as the code for the VI* can be used as the index to array TISTIR. 

This entry gives the starting point in TEEM1 where the terminals 
for the U* arc stored. Ghus A represents the range in which the 

tonninr.l T. ic to be looked for. In case of a match the TEHiiI2 entry I 

3 ' ! 

will give the information about the reduction routine I 

Patil ( 23 ) has implemented dries (is) groips of M statements | 

by a soqucncG of 'GO TO’s and checks , which examine and also 
call one of the six reduction routines to make appropriate 
adjuatmontc in stacks and to build the semantic tree (to be 
discussed later). A typical group is s 
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NSB IF (NL. NE. O) GO TO, 1.1 

CIJJL Sl(U) 

GO TO 9999 

H.1 IP (m. M3. U ) GO TO 1.2 
CiU[;L S2(u) 

GO TO 9999 

N.2 IP (NL, NE. U^) GO TO M. 5 

CALL S5(U) 

GO TO 9999 

« 

« 

* 

N... C;JAj EEEB (NSB) 

GO TO 9999 

Too .Logic bcahiixd the generation of GO TO «s is not very 
clear. A Ttnifiod scheme where N's fom the third dimension is 
cone Girtii ally oloaxer. However, as the matrix size mi^t have 
■become voay IfiXgo, writing GO TO's for only the pertinent TJ’& is 
away out. Howovor, if the oatalogae scheme is extended to 
inolado U> n (fig. 54) » £» economy in storage is possi-ble. As 
for tho spood, it remains essontially the same. P3X)'bably some 
marginal imurovoment may he there if binary search is' employed 
which now becomes possible in tho modified scheme. As for the 
storage each group now requires 5 words (3 tytes if byte arrays are 
used, as all tho infomation is less than 255 (9 tits) when 
considered as a number) as against minijunm 6 instructions (for 
IBM 744) oven if CALL is replaced by the setting of a variable I 
to subroutine number and using a 'oomiuted GO TO ^t. 9999* 



1(4 



Fig. 5.4 


S.No. “ aitroutine to Sg correapDnding to the six conditions. 
I?BDN « L.II.S. of the redaction. 

Fig. 5.4 


5.4. Bio S^Titox ~ Semantics Iifaddle : 

A, prohlom that occurs with the Algol 60 type of definition 
which v/j hiwc adopted for our definition of different 

typo of primrirysChoolean, axithmetic, character etc.) is that all 
of thorn 0X0 ultimately defined as variables. Bils constitutes a 
violation of the rule that each derivation ( in this case from 
■<:oxpr> to <variablo> ) be unique. A similar problem was faced 
by Wirth ( 55 ). Bio way to tackle this is that at the time a 
roduotLon is to be male a table search is done to see. the type of 
the varLablo and the appropriate reduction made. Biis decision of 
applicability of a syntactic nile on grounds of essentially 
semantic inf cannation reflects the axgaments that languages of the 
"Algol typo" are not, strictly speaking, context free. 
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Mother attempt to got around this difficulty was made hy 
making different types of identifiers as terminal units and hand- 
over the entire typo checking etc. to the lexical analyzer. This 
however, not only made necessary lot of flags etc. in the lexioal 
analyser, rendering it clumsy, it also inflated the size of the 
grammer liko anything. It was , therefore, decided to retain the 
inherent ambiguity and resolve it using semantic infomation about 
typo. 

5.5 Problem of Providing Enough Context ; 

Many times the grammer is not really ambiguous; still the 
recognizer fails because not enou^ context is used. For example, 
for a U*, T. reduction no attention is paid to. what is lying in 

the stiwk. The problan can bo taken care of sometimes by introdu- . 

cing additional non-torminals (UNTs) and a few extra productions. 
The vrucioun situations are best described by a few examples of 
situations that arose during the course of the project. Sometimes 
it may bo impossiblo to accomodate new additions to grammer, 
especially if the grammer that exists is to be retaiaed without 
drastic modification, in example of how this prohl-an came when 
it was decided to odd initiaH-zation facility in the deolMations, ■ 
is given towards the end. 

Consider tlio following produotionss 

' <a tcxm>-+. <a term> + m / IB ('I) <goal> -v <a term> 1 

<b torm> *J-<b term> g H) / IB (2) <goal> + <b term> ; 

where ® is some operator other than + . 
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Now Tor tlu' ruaitoiTCo ID + ID ^ the reduction process will go as 
follow.'’,: 



(id* con go Tooth into <a teiiii> 
as well as <13 term > which are 
Doth in the ^(s) of | ) 

if wo in tj’oi’nor; <id> ID | and introduce <id> for every 
occurfU'tCf! O’* 113 in (l) .-md (2) above, the problan is solved. The 
rooogniti.in I'rocoo-o now is ; 
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I 

! 
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<id> 

. ] 

r ■ ■■ ■■ 

<a.t.> 


•zz:^ ^ 











<a.t .-+*> 





4* 


<|)* 


’.'■i; iiru fcrar.tion of aU^U type of a prime phrase allowed 


tnki.n;;o‘ . 'air.f jioc; of tho loft context contained in U*. 

lla,; ?i,U)Vo oxninple is a simplification of the situation 
that ■ .t'.c?!'. 3 ’x*of! at many places. Hxe details of actual production 
would huon \tnnGCOssarily cumhersomo for illustration. 

ExfiTtplo V. % 

<hounl list> '»• i®0P INIEGBR s ADO P INTEGER (l) 
<‘b‘iund list> "+■ <'bound list> , ADOP INTEGER s 

ADOP INTEGER (2) 

tixpr^ ■+■ 03Cpr> ADOP <s teiin.> 

->■ iDOP < a term > 

■+<a texm> 

4 . <a pria > 

-*■ INTEGER 


<r, torra> 

< a prim > 

at a oerbr-dn ata^io in the recognition process say we have a 


(5) 

( 4 ) 

(5) 

( 6 ) 

(7) 


" " 

iDor INTEGER i "400? INTEGER 



7m^ 

: tj* ‘ 

-- — ^ 

A ■ ^ 



'i 



INTEGERS ... 





1CB 



« * w • » 

— 



— 

i 

i 




</JDOP*- pT*> 


Uu; ;m,;iln(:bionf,i marked with'?’ .axe possible because 
Ib'Q!* i.-. -u a-.itni r-rtaii (Y ) .'md it is indeed in the ri^t set of 
<ADOi>'‘' rrsin: (-l). Aluo <^j]) 0 P* - I!MT>* is possible from (l). 

Iho pr(.tbJ(j:i .'Lruu'o because the context that can be male use of. 
in tr. ih- ri, 3 it, 1110 previous typo of solution of putting a 
coiraiuin tu.ti-ica.’miiiRl does tho trick here too. ¥e, can write , 

^b'.jMKu! ll:!t> ■+• ADOP <integGr> : 4®0P <integer> 

i{.')wt'V»>r the grammer given in appendix gives bound list 
olemont JLhin not only makes unnecessary different 

sets of pratuotioun for-d.ntoger>. . <integex> , <intGger>.. 

/DOP <lnto4:>-'r> f /JX)P <intQgor>.. <integer> , and ADOP 
<intof?';r> ,* 1 K.)P <integer> . 

During tho swmantics it can be ensured tbat<expr>is indeed 
of the vru’Xuty douirod. Such a solution is in any case unavoidable 
if v/o 0 OC the PI/I call by value. ©le simple variable surrounded by 
bracks to in nji <oxpr> too and thus ® elemoat of the call list is . 
best taken an an <oxpr> - and tho call by value assumed when <expr>' 
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is of the tyi.:; ( ). This point is of course not 

rolcv.-int U-. Uu* i<xv,h;Uffl of i^rovidinpr context hut was mentioned 

in the f ' 1 {’ th<s nake I'if 0"mplGteness» ' 

=ri’e prtjvf.usly descrihed can not be uniformly 

applicil, li) ..istn-’j'uJi.x /i,2 it v/ill he found that at some plaies 

■<intcv:er> : 'ie-‘l nni ;it others INTEGER, the terminal supplied 
•mnlyzer , 

by the L ‘‘he .re-ionn is obvious from the example of the 

ruler 

<t' '' spool > INTEGER < format 3pec2^ (l) 

Now the n.t. <,Lnba|.:c‘r> can not he used because of operator 
grairmor rofstri ctiuno. The only way to use it will be to put the 
throe or four productions defining <:format spec2> in place of 
rule (l), the solution boing iterated if one of the rules has a 
non “terminal in tho beginning on the R.H.S. 

Moiiior twkwardnoss of the solution illustrated by the 

examplo of < bound list> definition, where <expr> was used..to 

define the bounds, is tho untoward expansion of the transition 
matrix oauaod by tho modification.' In the previous case the 
change of tho bound pair definition from INTEGER .. INTEGER to 
<expr> <exiTr> caused an increase in size of transition matrix 
by more them 2595. The increase is fairly irregular and could 
become critically large making packing of table entries essential 
even at tho expense of speed, p^blem could be more effectively 

tackled if tho non -ta finals introduced. we r# at the lowest level, . 
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so that 110 uiidaeirod symbols, vMch mil hajre to be later weeded 
out in ooniantioo, will bo permitted by the grammer. Ihat this 
is not always loosiblo is shown from the next example. 

Ml olcEicnt of the initialisation list oan be a signed or 
unsignal number, Oharaotor constant or boolean constant, if a 
definition based on the lino of example of bound list is 
attempted, we have ; 

<initial list head> INITIiL ( <ini element > (l) 

<initial list head> <initial list head> , <ini- 

element>(2) 

<initir.l list> <initial list head >) ( 3 ) 

<Lni olomcnt > iDOP <integer> I <integor> (4-a) 

iffilOP <fltpt> |<fltpt> (4b) 


At a ccx'tnin stago in the reduction process we shall have, 


INITlAli ( 



■<IlimAL*-( *> 


ADOP INTE&ER 

^FraiGER*> 

i 

<iDOP*> <integer> 



I / 

I 

I 


< expr> 


Pig. 5*6 



f±s 

Both tho ivcluctiona ( 5 . 6 ) indicated by the dotted as well as 
solid linoo nxe ix^soiblo, as U U* U required U to be in 
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left sot of tGiminal > , ' in this case, not bothering about 
the loft contort in<INITIiL* - ( >*. 

ilio Txnhlcra con be overcome by defining the initial 
eloraGtit n.s < 03 qir > . If howovor a non-terminal at a lower 
level ii,j docired, v/u may writes 

<0X1 -r ^ <unary-term> 

<un,'a.’y- term > -»■ IDOP <tciin> 

and use thu now non -terminal <unary term > in the definition 
of <initi;,!,l clomont>. Notice, however, that a non-terminal 
of tho typo <oignod integer > ->-iI)OP <integer>, is not possible 
as it can not bo common non-terminal for < initial element > and 
<oxpr > . 

IbLUs using <U-tem> will necessarily allow lot of 
undosirablo symbols in definition of initialization. In fact 
using <oxpr >will bo better as it would not allow significantly 
larger numbor of symbol combinations while taking care of 
all thu SLib rules of rule (4). 

5.6 Somantio Stacks t 

In Patil’s (25) scheme the recognizer has a secondary 
stack associated with the prsh down stack G 3 d.es' ( 15 ) algo 3 dthm 
uses in the recognition process. Another stack to hold iheU's 
and I" B forming the syntax tree was. also incorporated. 
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IJX- 

Range - 





I 


I 



I J 

U 

i 

I 

i 

» — IN.; 

T 

I 

i 


U 




T 



T 

■ ! 

5’ig. 5.7 ’ 




■ ! 


As rooognition proceeds U' s and T* s are pushed onto the stank 
and v/honovor a irc'd-uction with L.H.S. as aU is used, semantic 
routine G ."re callod with argument U. For each TJ pushed onto 
stack tho ronge of tho U is given opiposite it. 

Hovfcrvcr, as tho semantics are associated with productions 
and not tho non -terminals - a non-terminal may he on left of 
many iroductiono - it seems more sensible to put the production 
numbers in tho transition matrix. This is what has been done 
in modifying tho o«i«tractor for use in the present work. 

An array of left parts of productions is also generated 
which helps got the U to be used in the farther reduction 
pTOCGss. Tiiou^^, to build a tree the ranges may be helpful^ 
tho information becomes redundant if we put the production 
number itself on the stack. As sinultaneous processing by 
semantic routines will be assumed this has not been necessary. 
The rango is not maintained but can be incorporated very simply. 

In addition to the six groups of statements three more 
have boon added. The detailed description can be found in . 
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mio firnt, i.o. /jroup 7 , ia to take care of the 
formation of the fin^l goal non-toimiinals (though there may 
be only one diritingiiishGil aymbol according to the definition 
of phrane stiucturo granuner ( 15) , this oan be achieved tri- 
vially by ru-bling a fovr more productions in the grammer, 
deriving the present ;pal non-turminals from the distinguished 
symbol). Mie final statement (Appendix j'^,2 ) is of the form : 

<i'!tcitoiaont > opjocifio statement >,. 

Just 'bcfciro the goal non-terminal is to be formed, we have , 

< (j,* - fniocifio statement >•*<• in the stack. Anew 

terminal is needed to reduce the phrase to < statement > . In 
some oasorj wo could stop at <specific statement> only. But 
then for the j,a?0(3uotion <0lso statement> -»■ _BhSB 5 , 

< <l)* ELIjB >* together with any terminal will fail to find an 
entry in transition matrix. Ihus in both the cases error exit 
would be norm.ally taken. Instead, we branch to the 7th group 
where wo ohook the U* on stack. If the U* is corresponding to 
the above oases, the TOduotlon^ <statement> •+ b*, is made and 
appropriate semantic routine called. If. b* is not of ihe type 
described above, the incoming terminal is unacceptable and the 

sentence being recognized is in error. 

The two other groups have their origin in. the decision to 

retain the chains of Ihe type ^2 ^5 ’ syntax tree. 

This is to be discussed next. 
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5 *7 Retontion of Chains s 

In Patil's constructor no provision is kept for main-, 
taininfj chains in syntax tree. When a reduction according to 
condition (2,3) is made (U •+ uf , and Uj^ ^ ) stack 

no record is kept of the occurance of 

in the syntax tree the bottom node in a derivar- 
tion is 'Iho only one appearing. This probably is in pursuance 
of the vicivir of Grioa that no interpretation rule is usually 


associated with 

not the case. 

.... e-U^. But many times thi 

s is 

Talco for example the 

following production for l/o 


statement (Api>endix A. 2): 

- 


<I!ut list stmt> 

^ HIT lAST ( <iut list> 

) (1) 

<Xiut list> ' ->■ 

<e3!pr > 

(2) 

<]mt list> 

■<put list> , <expr > 

(5) 

<gct list stmt > ->■ 

GET lAST ( <get list > ) 

( 4 ) 

<gct 31 st > 

< variable > 

(5) 

<got list> 

<get list> , <variable> 

( 6 ) 


Row in processing a statement GET UST (ID, ID), we, shall have 
at one stage s 
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Thus the processing corresponding to get list can 
he done only when the ri^t bracket has been absorbed. If 
however, we maintain the chain and duly get the also 
recorded, Y!e shall come across get list for every lb from 
rules ( 5 ) and (6). The problsn between put list and 

get list does not arise, as the lb's in both cases, first go to 
a common non-terminal„(fig. 5 '>b). 


<GET*-IirST-(>* 




<get list> 
<get list-,>* 

<id> 

<Ib*> 


Ib 


<get list> 


<get list-,>* 



<get list> 

/ 

<Tar> 

/ 

«:id> 

/ 

<Ib*> 


/ 


Ib 


1 


<var> 

<id> 

<Ib*> 
Ib ) 


s Partial syntax trees with and vjithout chains: 
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The decision to keep' chains invoked a modification 

of the constructor. Sig description of the modification requires 

dot :i led knovr lodge of constmetor meohaniism^ hence it is not included 
here. 

imhignity SGsolution s We talked of the ambiguity that is 
contained in the syntax of expressions in the section ' Syntax- 
Sera artice-i'-'lndd le ' . The chain maintainance allo-ws the resolu- 
tion of ambiguity in a convenient visy. At present, after the 
<id> is transformed into <variahle >, th9<variabie>oan at times 
go into different primaries. Take the parsing of the .following 
statement : 

A = B 5 

cb IB IB I 



The marked paths are due to the paths vi a<a-e3pr><b expx > and 
<char prinary> . Thus searching corresponding to B too -will 
have to be done in the<assign s'tmt> . 

Similarly the ambigui-tdes arising (or idle searching in 
symbol table to be done corresponding to <var> -*■ <id> will not 
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"be possil3le as <Taa?> simply is not formed (it is skLpjped) 
in tile .reduction process. (Note that at <id> no action can 
he taken hociaise identifiers in many different contexts - 
labels j procedure names etc. - v^arrant different tx'eatments) . 
Also care rill lieye to be talcen a,t different points as the 
above iroblem may arise when <rcl expr> is being formed 
and in xDroductions ’jiiere <rel sxpr> occurs in right parts. 

'This will not only necessitate the use of flags to indicate 
whether or not symbol table search etc. has been performed, 
it TiTill rj-so violate the natural and uniform processing by 
delegating more and more things to the algorithm instead of 
the tables. 

In the modified algorithm when such a situation arises 
the number of rnothor, i .e . the 9'bh, group of statements is 
stored in transition matrix. Now in a iituation like (fig. 5. 10), 

<id > 

! 

I 

<var > 

< a prim 

Nig. 5.10 

the type of variable is checked and appropriate reduction made. 
This is imich more urdfom and oonceptiona.lly simpler than 
handling things at a thousand different places. 

"Mlc at it, the reason for providing a second syntactic 
level above <id> , i.e. <id foim> , <id proo , <label> , <var> 


> <b prixii> <c Tjrim> 
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etc. rncy 1)0 mentioned. Odiese entities require different 
treatment viiich is oonTeniently provided Ydien <id> is 
reduced, to one of these syntactic entities depending on the 
context. 

^ fonolusions; 

One of the limitations is the problem in shaping the 
grammer to meet the conditions 1 and 2 j which has already 
been illu-strated by examples. This problan becomes specially 
important vfhen grommer is extended to include extra features 
that it does not already have. The people extending it, have 
to see the implications of extension on rest of the grammer, 
even when it is obvious that the extensions do not make the 
grammer ambiguous. Second problem is that of the inordinate 
size vrhich can be tackled only by using .the packing schoao 
suggested in section 5.3. 

One of the major advan.ta.ges of transition matrix technique 
is the possibility of giving specific and extensive error 
messages. Th.is can be done quite easily (manually) by putting 
the error message number in the G-ries' 2 dimensional matrix. It 
seems, ho v;over, that the error message should depend upon the U's 
too and the rna.lysis will have to be done by a subroutine whose 
number ma.y bo lut in the Gries’ matrix. The process will of 
course not be so easy in the present sohane. On failing to get 
the entry in the transition matrix, a second set of tables will 
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will htWQ to 1;0 se-nxched to get the erior message number .Manual' ^ 
insertion is not possible as all the terminals (T..) for a 

t] 

U* have to he together, and insertions thus will spoil the 
ca,t.-ilogixG system. Eli s could, however, be mtomated hy 
providing the set of error message numbers with the combina- 
tions to the constructor, .and let it take care of the inclusion 
of theso in tr.5nsition matrix. 



CHAPTER 6 


SI21TM. A:ULYSIS MD mOGEJiM STRUGTUBB CHECKING 

In chapter 4 we gave a general description of the whole 
inplenentation. !rhe intent of this chapter is to go into the details 
of the syntax analyzer as well as the driving routine and also talk 
a little about the general organisation of the min semantic routine. 
The details of individual semantic tasks will be given in chapters 7 
(part I and II ). The description of semantics in the present 
chapter will be confined to the checking of program structure and 
the initia.lisations etc.^ required for processing new statements 
or procedures. Most of the description will be based on flowchar'cs. 
Discussion of special strategies etc., will be given when vyarrantod. 
Eor details of common areas and description of various data refer to 
Appendix 

6.1. The Driving Routine i 

The main purpose of the driving routine AEIDEIY is to look 
after the transition from job to job as well as transferring control 
to the quadruple pracessor. Details of how this control is exercised 
is described in section 4.6. At present we shall assume that the 
task includes compilation of single job. 

Ghe block diagram (fig. 6.1 ) is self-explanatory. The 
only thing that need be explained is as to what initializations are 
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Ib tfake upj 
a new job | 


'X' 

\ 



T 


Read the transition tables and the 
first colimin of the matrix IS. 


\ 


Set timer and call initialization 
routine (EXTIRI) to prepare for 
next.iob ^ 

.>V. .. - - TT 


S 


Check for the procedure options 
(liJain); statement. Ignore all 
trash that precedes it. 


-1/ 



i 

t 

Time the job. ; 

Print compile time ^ 

I 

\/ 

I 

If no error transfer control to j 
quad. Processor or set a flag 
which will result in doing so. 

If error-take the opposite action. 


iig. 6,1 
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(ione^where. There are two main initialisation routines EXTOTI and 
IKTIiilTL* Esctini initializes various pointers and semantic stacks 
and tables etc* The iniatializatioh of individual stacks etc., 
is given in the proper context^ i.e. at the places they are used* 
INIiUSTL is a routine that initializes the syntax stack and this 
initialization too is described in the description of syntax 
analyser that follows. 

6.2. The Syntax Analysis Routine : 

The routine AWLZE is activated by the driving routine 
iUNTDRIV and it transfers control back to AKTLZR only when the character 
signalling the end of job is encountered. 

Irinarily the syntax analysis process goes by using the 
recognition technique described in chapter 5. A push-down stack 
STAK1 is used to hold starred nonterminals and a variable RL to 
hold the current (if any) unstarred nonterminal (u). The stack 
STiiK2 associated with STAKl was earlier used for holding the ranges 
of U*s temporarily « TRRS1 TEIEB2 and TREE3 are three stacks used 
to hold the partial syntax trees and associated semantic information. 
In the initial version a linearized foxm of the tree where pointers 
with the nonterminals to hold the last terminal in the range were 
kept (section 5.6) was used. In the newer version the production 
numbers are loaded on stack and there is no necessity to keep the 
range* As such the statements relating to the range are superfluous 
but have not been removed to permit later -modification, if any. 














124 


The recognition process (fig. 6.2) goes as follows : 

a. Initialization ; Syntax stacks are initialized in routine INIMTL 
called once before AKfLZB is activated. Initialization consists of 
setting pointers for STAK’s and TRIS's to 1 and putting the codes for 

in 3TAK1 and in IKEE1. <l>* is a special starred non-ter»iiinal 
which derives the special tenainal (j) which is assumed to be appended 
to every sentence to be recognized. IL is set to zero.HXTTRM which 
a flag indicating whether a new terminal is needed (true) or not 
(false) is set to TRUE. 

b . Getting the lUext lexical Unit : 

The lexical processor BXTIIM is called to get the code 
for the next terminal (Lexical unit). The infonaation is placed 
in the common area LEXITM. IC is the code of the tenainal returned. 
IC2 is secondary information, e.g. the -type (PIXEL, PEOAT, etc.) 
associated with the lexical unit TYPE or pointers to constant tables 
in case of constants. The code is examined to take actions required 
to properly indent the output listing. Por details of indentation 
scheme refer to section 6 . 3 . If the code is of I then control 
returns to the driving routine AELEIV. MTTRM is set to false . It. 
is reset to true if, depending upon the red\iction to be made, a new 
terminal is reqiiired. 

o* Getting the type of reduction to be made i 


Subroutine GETSBU (fig. 6 . 3 ) is called with arguments ; 
the unstarred nonterminal (lP<-) on top of stack (STAKI (STKPTR)), 




I 



SFT: Starred nonterminal HI; nonterminal T; [Terminal 
KSUB: The iype of reduction. [TELiUS is the common area for 
transition tables EEM: [Eh.e code for the starred nt. or the 
prodn, no. given in the array D3. 


: Subroutine GETSM: 


Eig. 6.3 
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the mstarred nontermioal (ui) and the present terminal 10. Ihe 
subroutine GETSBN searches the transition tables and returns one 
of the eight (1--6 and 8,9) type of reductions to be made (SFO) and 
the code (EEIN) of the left hand side of the production to be used 
(code for or the production number (in case of a nonterminal U)). 
When GETSM does not find an entry it returns 7 as the value of 
SFO. SNO is used as an index to a computed GO TO to transfer 
control to one of the 9 groups of statements for making different 
reductions. 

d. The Reductions : (fig. 6.5) 

The reductions El to E6 are corresponding to the six 
conditions given in chapter 5- The significant points about these 
are : 

After taking care of the ST4K1 and HI (found from the array 
IP of the nonterminals for different rules ), the routine SEMAEiT is 
called if the reduction is of the type U -v II*‘U or U •+•0^, the 
argument being the production number. The routine ASTEIEE is called 
to build the syntax tree. The flag HXTTEM is set to true if the 
reduction uses the terminal. 

The reductions E8 and i© have been introduced in the 
present implementation to build the chains in syntax tree described 
in section (5.8). E8 calls the, routine SEMAK and then calls ASTEtBE 
to build the chain in TEJEE1 . H9 is to take care of the case-vdiere 
ambiguity arises, as described in chapter 5. An examination of the 
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' -/ - ' y 

6 . 4 . ' : 

jiNAIZfS is the coiamon area holding stachs SiME & IEEE 
lEXIM is the coumon area holding IC & IC2 ©to. ! 

Subroutine ASIESE: 1 

I 
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C3( 


Nl/ 


I ]!T1>=IP(EEDN) 


vi 


Pop the STiiK 
S!KP!rE=STKP!IE-1 j 

J 

/ 

Do semantics: 

CALL S£llVIAN-(RBDSr) 

J 

VJ 





El : U U* 


oC 


!EI>=IE(EBDN) 


■J/ 


Do the semantics; 
GAIiL SEim(BEm) 


Build syntax !Cree s j 
Gall ASKpS I 

n!/' 




Jl 


oi 


Replace the old U*: 
STAKI ( SOKPOB: )=REDF 


Stack the new U*: 
Sffi:PIR=S2KH!R+1 
STAK1 (STKPIE)+EEDN 


\ 

/ 


Indicate next termij; 
will needed: 
1JXTTRM=. TRUE. 

lajl , 

E X THM = .TRUE. 


i 




Build syntax ilree; 
CAIl ASTREE 

Build syntax free: 
GAIL aSIREE 

! 


'j/ f. 

E2; IF -i- IFP 

<x. 

± 

E35U**~>!r 

a 

Eeplace the old IF: 

siaki(sikpie)=reiit 

i _____ L 

Stack the IF: 
SIKPffi=S3EP!I!R+1 

>1^ - - - 

o 

II 

H=1 

I El = 0 i 

i f 


Pop the SPAK: ' 
SilKPPRr^IKPPR^I 


^ — 

Eext terminal' will 
be wanted; 

EXTTRlfc. TREE. 

_ __ ^__ 

'i" 

Eext terminal will be 
needed; 

j EXTTRI€=.TRIIE. 

\ 


■ ' ■ ’ ' 1 

J, 

Build the syntax 
Tree; 

CALI. ASTREE 

. 

Build the syntax 
tree : 

CAIl ASTREE 

t 

1 Build the syntax tree 
j CALL ASTREE 


' 1 . 


0 


E4 : U *'U*U 


h 

c 


'■i' p 


E5 : D* tJX- UP 


E6:IP<- c-UP 


Bae nine groups of statements for different reductions: 


lig. 6.5a 











U’irfit terminal of 
next statement has 
prohahly been read: 
NXT'M=. FALSE. 


Chock if U* corres- 
pomls to the one 
belo'.-/ goal 


Is xt? 


Illegal terminal 
skip to next semi coin 
CiiiL EEaDR(llC) r 

(110 is the error code) 


Set the HL 
apjiropriately and 
IHuIE to the appro- 
priate redaction 
(it TJ*),do semantic 
for appropriate stmt 
QlJh. SEI.Lm(lEULE) 



replace the old U: 

il=ip(eem) 


Ho entry in transition table. 


R8: U1 











4 

\o( 



■ Check type of 
from KiEE 2: 

the variable i 

IPiiDE='IEEB2(lRPBR) 
b CALL GETATRO) 

ITY'LE=Am(l) 

’L-.- 




Set I'lL to 1)001 prim 
IRUIE to appropriate 
rule 


Do semaati-cs 
CALL SEWMClICrLB): 


130 




character 



Set NL to a primary- 


Set NL to char- ' 


IRIJLB to appropri- 


primary 


ate rule 


lEUIE to appro pari- 




ate 



Build the synatx tree: 

call AS-mHE 






E 9 : Resolution of Ambiguity 
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type of variable is made and paroper reduction decided accordingly. 

Reduction H? is to take care of the recognition of the 
final goal or nonterminals 52, 53, 54 . As pointed out in chapter 5 
at the end of reduction of a . statement, a U* corresponding to 
these goals keeps sitting on the SlilKI and a reduction of the 
form U— ^ D* is required. When the next terminal is absorbed an 
error condition occurs and GETSM returns the SRO as 7* Then E7 
checks for the presence of proper U*’s on the stack J^f found, proper 
goal nonterminal is set as NL and the routine SEMAKT called. If not 
the incoming nonterminal is in error and the subroutine ERROR is 
called wi-fc appropriate error code. ERROR routine in this case 
skips to the next semicolon and calls IRIAliri to initialize the 
syntax stacks etc. UTIARL is also called by SEMAN when a statement 
is recognized. 

6.3.' ^formatting ; the Irogiam lasting ; 

Ihe above feature referred to in chapter 4, thou^ 
doubtless a great aid to progf^ mceadability, has been incorporated 
quite simply in the fashion described below : 

An output buffer of 131 characters is maintained. The 
routines GETCHR and NOBIiRK of lexical keep putting characters in it. 

I'rint-out takes place by explicit commands to the loutine EISODU. 

This occvirs, when (l) output buffer becomes full in GBTOHR or lOBEKE 
routines (2) a , THEF or ELSE is supplied to AFIiZE, (3) a 

comment occurs (this is printed on a new line). 
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To properly indent output listing the margin is increased 
or decreased by signalling to the routine XISIDU by raising in the 
routine MIZE the flags lECELG- and DEOEIG respectirely . IP-THEJU, DO, 
BEGIN, EEOCEDUEB increase the margin. ELSE and END restore the . 
margin. In case of errors sometimes the part of the statement in 
error gets printed out followed by the error message and then by the 
remaining portion of the statement. A sample of the unformatted 
input program and the foimatted program listing is given in 
Appendix C . 

6.4. Checking the Program Structure : 

The goal nonterminal of the syntax analyzer could Mve 
been kept as the < pro gram > itself . <statement> could also have 
been defined as, <simple statement> and <compound statement > . 

Thus by making various compound statements and procedure etc., as 
syntactic entitieSj the structure of the program co’uld have been 
checked in the syntaS; analysis process itself. This has the greatest 
disadvantage of exploding the tiansition matrix size, which is 
already critical, possibly to unaccomadable voltme. Also H/l 
(and thereby MINIDl)has a syntax quite naturally fitting into a 
grammer where the smaller units are treated as goals. The explicit 
termination of statements by' ;* is in contrast with Algol where the 
compound statement is absolutely identical to a simple statement, in 
as much as this too is terminated by the semicolon. However, treating 
the simple statements, as goals necessitatesmaintainance of histoay in 
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another stack as will be seen in the following material. 

The productions with L.H.S. as the nontezminals 52, 53> 54 
(Appendix A, 2) are corresponding to the definitions of statements'^'^ hen 
SEIIM is called wiih these production n:mbers as the argument, 
processing to check the properiety of the program structure is 
carried out. 

The description in this section mainly concerns itself 
with the portion (not necessarily physicallr) of SSMAF that deals 
with the structure checking. The approach will be mainly based upon 
the semantics stacks and their use' to check striJcture. Ifewever, 
the semantics, specially generating jumps etc. for conditional 
statements is deeply related to the matching and nesting of clauses 
and these are best described together. Thus in the present section 
we shall describe the semantics for the aforesaid statements; for' 
the other ones details of semantics will be given independently, 
ilrsi wS shall Took - at what is involved in struc'ture checking, then 
give the method- adop^d 'fhliowed up by *a description of the mR-io 
semantic routine SEMACif tc 'fix: up 'the ideas. 

Ibr the puipcses of structure checking we shall classify 
statement into the following categories : 

1.<if-then stmt> 2< else stmt4 3- <^begin stmt> 4. stmt> 

5. <,end stmt > 6. <.Declare s-tmtl 7. all other <stmt'>s . 
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Things to be checked are : 

a. Nesting of DO - groups and PROCEDURE and BEGIN blocks. 

b. I-l’oper nesting of the IE-THEN and ELSE statements 

c. Occurances of declarations and procedure definitions at the 
proper place in any block, i.e., declarations first, then 
procedures followed by executable statements. 

As for the check (a), all tlBt is required, is to push 
the code for do, begin, or procedure onto the semantic stack. Also 
a flag is maintained for each block which tells whether an executable 
statement a declaration oraprocedure definition has occurred 
in the block or after the most recent if-then or else statement , so 
far. To see what is involved in checking (b) let us examine the if-then- 
else statement of MINIPl. 

The general foimat is, 

^lE • ,b exp THEN- SI ; S'} 

,;±f-then statement 

■ IE b exp ;■ THSN. SI; ELSE S2; S*; 

' else 

• ■ ' .. -st mt 

if -then-e Ise-s tmt 

where, SI and S2 are either simple or compound statements. .The 
occvirance of the statement S' indicates the completion of the previous 
if -then or the else-stmt . An if-then stmt immediately followed 

by an else-stmt ' forms an if-then-else stmt . The problem is to 
see if these conditional statements are proper becomes complicated 
in the situation where there is a nesting of conditiorals. 
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Example 

IE <b exp1> THEtr IE <b exp2 > THEKT <stmtl> ; ELSE 
IE<b exp3 > THEN <:stmt2> ; <stmt3> 5 

JJow, the fact ttjat the first if-then does not have an else counterpart 
can be knownonly when stmt3 is recognized* Ihe most important 
thing in the semantics of if— then-else statements is 'pTOvision of 
proper jumps. 

Example : 

a, IE<b exp> THEN <sl> ; 

When the <b exp > has been evaluated a system label is 
generated and a conditional ^go-to to this statement is generated. 

After si is recognised the old label generated must be defined. 

b. IE <b exp> THEN IE <b, exp’ > THEN <s1> ; 

. ’ The .Zbabel defined for the first if-then statement can be 
used for the go -to in the second if-then too as in case of any of the 
<b exp> ’s being fal^esa jump beyond the <s1> is to be executed. 

This label will be def inefi, the statement <s1 > is recognized. 

Hie structure processing part of the semantics assumes that rest of 
the semantics for the statements are already over (e.g. evalmtion of 
<b exp> in case of an if-then statement). 

The Structure Checking Algorithm : 

The main stack for semantics is in fact a set of stacks 


MS5K1, MS!IK2, MS3K3, vihich store information about the tSTpe of 



1 5^ 


currently active program structure entity, the flag indicating 
the status within the structural entity (whether a declaration, 
procedure definition or an executable statement occurred), and 
names of associated system generated labels* if any. The details 
of label handling are found in chapter 7* S't present We shall just 
give the operations we want on them* here. 

The algorithm described below gives the actions taken for 
each of the 7 categories of statements defined on page 

Init ialization : It is assumed that an external procedure is sitting 

in the stack. 

Step 1. Place the top elements of the three stacks MSTK1 , MS!IK2, 

MSTK3 in the variables TOr, STATOC and LABOID (changes 
in STATOC etc., will indicate that top of stack is being 
, Changed too , popping subsequently will. include the 
appropriate adjustment of the three variables). 

Step 2. Jimip to ,apprO|)riate step depending upon into which of the 
seven categories referred to above, the present statement 
falls . 

Step 3. g if-then stmt> 

3a. If TOP is not a conditional, then make the SIAIDC = 1, 
push the current if-then on MSTK1 with the MSTK2 as 
0 (no statement yet occurred, generate a new label aM 
push it on MS3K3* and issue a conditional go— to Iw this 
label, return . If TOP indicates conditional, go-to 
step 3b. 
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5b. If no stateraent bad occurred (i.e. S!Eil!D30 - o) 
after the previous conditional, push the if-then 
on MSITKl , generate a new label and push it into 
MSIK5, issue a conditional go -to to this label, 
return . If a statement had occurred (i.e. STA2DG o) 
then go to step 3c. . 

3c. I'op the TOf until it indicates something other 
than an if-then or an else , push the new if-then 
onto MSOKl, generate a new label and issue a 
conditional go -to to it, return . 

Step 4. else stmt 

4a. If IDE is not a conditional, then print error, 
return . If it is, go to step 4b. 

4b. If no statement occurred before this else 

(SdJAITOO = o), print error, return . If one did 
occur go to step 4c. 

4c i As , an if-then , pop the if-then, push 
\the else , '^aerate a new label, issue an 
unconditional go -to to it, define the lABOID, push 
the new label onto MS3K2, return . If lOP was not 
if-then, go to step 4d. 

4d. (The TOE already has an else which had a statement 
after it), lop the else on TOE, Go to step 4a 


(to find a matching if-then ). 
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step 5 • < begin statement >■ 

push the begin on TOI with STATOC = Os do rest of the 
semantic processing, return . 

Step 6. -^do statement^ 

push the do on TOP, push the label for return from end in 
MS TCP (STATOO not used for do), generate a label, push it on 
MSI^ and issue a conditional go-to to it (this condition 
is the termination condition of the iterative do-group 
which has already been evaluated. If non-iterative 6 £_, this 
action is not to be taken). 

Step 7. -cend statement^ 

7a. If TOP is not one of begin , do or procedure ^ print error, 
return . If it is, then go to step 7b. 

7b . If TOP is begin or procedure , do the required semantic 
,, processing. If it is then issue a go -to to the 
; label for another iteration, define the label for the 
• , termination go -to. ' Pop the TOP. If TOP was procedure, 

return . ;■ .If ,;® ; wa.s begin or go to step 8. (Since 

the compound statement is now recognized, which is 
equivalent to an ordinary statement for purposes of 
if-then-else . ) 

Step 8. Other <statement>s 

8a. If a statement did not occur , make STATOC = 1 

(statement occurred), If IG (next terminal) is an else, 
retxrrn. If it is not, go to step 8b, 
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8b, If a non-conditional on !IDP, return . If a conditional 
on TOP go to 8c. 

8c. Define the LABOID. Pop the stack, go to 8b » 


Fote ; A point or two about, the above algorithm are in order. The 
processing for the begin and piocedure blocks and their physical 
ending involves tasks related to storage allocation -and symbol table 
management etc., and hence it's description is included in chapter 7. 
Secondly, there is a slight difference in the order of actual processing 
for the category ^other statements', liie main semantic routine SMAIT 
first does the processing related to striacture and then goes to the 

'main computed go to' for processing of individual statements. 

The following example will illustiate the algorithm described ■ 


above : 

begin'’ 

• 

ip<b ■exp>'’ 

IE <b expj,^ OEEN^ 



ELSB^ 

IE b exp ^ THEtP 
32 ; 

EIBE^ 

S3 ; 

34 ; 


Code generated 

•j 

Branch on false, exp> , LABI 

Branch on false, <b exp^ , LAB2 

• 2 
ICode for Begin block 

« 

Branch, IiAB3 
Define, 1AB2 

Branch on false, <b exp;:- , LAB4 

■ :Code for 32 
Branch, LABS 

Define, LAB4 

'Code for 32 
Define LAB5, LAB3, LABI 

I Code for 34 
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Nojtes '.I'hc capcxcscripts in the preceding program are just for 

ol.”.rj.ty, OCCUR indicates a -statement has already ocouz^red, 

OCCUR indicates , it has not. h easp in the following 
figure, \d.ll represent the loca.tion in wMch the result 
of evaluating h exp is stored. 




Generate s Branch on false, <h exp> , 
L1B2 

* *( few steps for the stateme-j 

""nts within the BEGIU^ 


hlock 


f 

f 


Fig. 6.6a 
































Theok if 
a procedure 
heading recogni- 
sed? 



Print Error 
'External procedure 


awaited* 




Call EXmT to flush 
the trash, prepare for 
next external procedur^ 

I 


aL 


Return 


-i: — ' 

Print ! 'Ext, proc- 
dure started' and 
do the necessary 
semantics. 
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6.5 The Routine »SEMM ' 

SEMM is the main semantic routine and is activated from 
syntax analysis routine MLZR with production number (ISEIE) as 
the argument. It does the s^mantic processing for the syntactic 
entity recognized and stores information in the secondary syntax 
stacks (TEEE2 and THEB3 ) and also maintains main semantic stacks 
described in the p3::evious section, for structure check and other 
reasons. Due to the large variabili-ty of iiie information maintained 
and manipulated for semantic interpretation of different syntactic 

entities, it will be neither meaningful nor feasible to describe .the 

% 

whole program here. The flow chart in fig. 6.7 gives at a macro- 
level the general flow of control valid for all syntactic entities 
as a whole, in important array not mentioned before is EHS. This 
contains the number of terminals or non-terminals in the right 
hand side of each production of the input operator grammer. As 
shown in. ihe'fiow chart, TREEl is popped to clean all the symbols 
in the present hahdl^.''' ff however the symbols have to be retained 
(though it is dangerous and the effect should be taken care of) 
the corresponding E.H.S. entry can be made zero. Notice that 
information attached about the handle in TEEE2 and TEiEE5 

becomes associated with it when the new non-terminal (to which the 
handle has been reduced) is pushed into the syntax tree THEB1 by 


the routine ASTEEB 



CHAPTER 7 


SPiCBOE TABLE MilSTAGMMT, STORAGE ALLOCATIOIT AITD 
RUE TLME ADDREGSIEG 

7.0 In this chapter 'ffe discuss three important aspect of the 
MIEIPL compiler sementics. Various basic piDblemSjalternative 
solutions, design decisions for the present compiler and essential 
details of the present implementation are given. In section 7*1 
we discuss the symbol table organization and the processing of 
declarations. The next section describes allocation of addresses 
to variables in MIFIPI. The section also outlines the features 
of a Quadruple Processor which will make effective use of the work 
done at compile time, by contrasting it with the implementetion 
utilizing the MAP assembler. In the last section (7.3) we describe 
the mn time storage administration and also the relationship between 
the instruction set of a particular machine (iBM 7044) and dynamic 
areaaddressing. 

7.1 Symbol Thble Management ;?, 

Symbol table is one of the most important repositories of 
information in the compiler. It stores Information about all the 
identifiers-labels, variables, foimal perameters, procedure names 
etc.- of the program. It is accessed by most semantic routines to 
extract the information about an identifier. Hence it is essential 
that its organization allow efficient searching and extraction of 


attributes 
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7.1*1 Basic Organization : 

Evans (10) has described the symbol table as a means of 
converting the 'character strings ' representing identifiers into 
integers which can be -used as indices to access a table of values, 
each entry of which corresponds to one entry in symbol table and 
contains the information for that identifier. We shall consider 
the symbol table as consisting of an argument column and one or more 
value (or attribute) columns storing information about the identifier. 
Ihis description implies that for eveiy identifier in the symbol table 
same number of cells are kept for storing its attributes, possibly 
a waste if the attributes for this particular identifier are less 
than the maximum number possible. Probably keeping this in mind 
Eamarao ( 27 ) has provided for a mechanism of obtaining cells from a 
free list, and linking them up in a list to form the set of attributes 
for a given identifier. Ifcwever the mechanism of accessing 
attributes becomes slow for two reasons: chasing the pointers and 
seeing the Class to which an attribute belongs (this is fixed in the 
tabular organization by assigning one coltnnn to each of the classes). 

A class in the above context is defined so that an identifier may 
not have two attribute in the same class (e.g. fixed/float/char/... 
may form one class, static/automatic/.,,, forming another). [Qae 
number of such classes for different identifiers does not vary 
considerably in a reasonably modest langixage -making the waste in the 
tabular organization minimal. !Ihis is the case with MUIPI too, 
and we have a tabular organization, details of which are to be found 


in section 7.1»3 
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If the identifiers are required to be of fixed length the 
argument column of the symbol table contains the identifier itself. 
In most cases however, as also in MIIJIPI, the length of the 
identifiers is variable. In such a situation, the argument column 
points to an area where identifier strings are stored- Ihe 
length of the string may be stored in either the argument column or 
at the beginning of the string itself. Ihe latter scheme (fig. 7-1 ) 
is used in present implementation. 

argument col. 






— 

* 

1 " . ^ 



il 






' 


- 

* 

•f 

«. ; ■ 

. f < » 

^ , 
i " 

, ^ 

f- ' , < ' - ■' 



^ '' ' , ' string area 

7.1.2 Block Structure and Symbol (Table Organization ; 

Evans’ (2 7 ) consideration of replacing an identifier, 
as soon as it is read in, by an integer (index) in the symbol table 
comes very natural in a language like EORmAlI. Baere, for the 
first appearance of an identifier it can be entered into the symbol 
table, all later appearances being replaced by the index of this 
entry. With the block structured ianguage~MiniPL is gsne of th^ - 
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the situation is not so simple. Olhe same identifier may be declared 
and used many times in different blocks and procedures, and each such 
declaration must have a unique symbol table entry associated with it. 

Ihe technique used in hlDOH compiler ( 17 ) was to prepare an 
identifier list and a block list. The latter pointing to the id -list 
to give the starting address and number of identifiers occurring in 
this block as also the number of the immediately surrounding block. 

The facility in languages, of using identifiers before they are 
declared, makes a pre-pass essential; this pass is required to do the 
analysis of the block structure and declarations. It is suggested 

that most statements be skipped and a short grammer for declarations i; 

r 

and block structure be used in pass 1. This however seems to have f 

the disadvantage that identifiers (not in declarations) either have ^ 

to be read again (and built up as id's) or we have to store them all ^ 

f 

in an internal area from which they will be accessed when referring [ 

■ - . ' [ 

the symbol, table, Sa the scheme used by Gupta et. al. ( 1®) • . a | 

name table is prepared i^ pass-1. This table contains each identifier i 

at only one place. As and when a declarations for an identifier is ' 

processed an attribute cell is fetched and linked in the list of : 

attribute cells which were linked as a result of appearance of this I 

identifier in declarations in surro landing blocks. i 

As discussed in section 4*4 two passes were no longer a must I 

t 

because of the MINIIL restriction of having variables declared before t 

( 

f 

use; in fact declarations are to be the first thing in a block. t 
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If two passes did become necessaiy because of core size limitation 
in some particular implementation, the block structured table of 
1I/30R (17) type could be used. The other choice (18 ) seems to 
involve more work in implementation, as a list organization is 
required, as well as while compiling, as pointers linking attribute 
cells have to be chased. 

Present scheme uses a table analogous to the first scheme 
discussed above. We t ak e the advantage of cur one pass organization 
to make the searching more efficient and probably effect some 
economy in table size. -The scheme Involves, at the lexicographic 
opening of a block, setting a marker to the starting point, in the 
symbol table, at which the entires, if any, for the current block 
start. ibr every declaration a search is made up to this pointer 
and if the identifier is not found, an entry is made into tfe: table. 
As soon as the processing of the block is over the entires for this 
block are deleted from the symbol table. Hius at any given time 
only entries corresponding to the currently active block will 
occupy the ay^tol table. Sje search for a use of an identifier can 
be made in the symbol table, last symbol backwards. The overhead 
in looking up the parent blocks and their addresses from the block 
list is now no longer there. In fact in the present one pass 
compiler there is no need for a block list, and consequently one 
is not constructed presently. 

Hash addressing is relatively difficult for building symbol 
tables for block-structured langmges. One important minus factor, 
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2 

in a symbol table attribute. 'When block BEGIN is opened and , 

'GO TO II' is encountered li'iBCNT is increased by one,!! entered 

in symbol table and LABCNT value (say n2) stored as an attribute 

2 

for LI. If any more 'GO TO II' statement occur in BEGIN block, 

the same labcnt as stored fbr Il(n2) is used as Ihe operand in 

2 

the quadruple generated. It the time BEGIN block is closed all 

labels referred in it (of the H type) are looked up in the 

predecessor block (BEGIN ). If not found, they are appended at the 
1 

bottom of BEGIN block entires in symbol table. If fotind,as for 
the progrem in fig. 7.3 i then an entry is made in a separate table; we ■ 
call it lABIkB as shovan in figure 7.4. Ibe pointer to the entry ■ 

ENl in LABIiB is stored as another attribute against the II entry 

i 

(for begin”' ) in sjmibol table. | 

Olie label counts for same label II in surrounding ^ 

The lable point for H in the beepest block. blocks , j 

[ 

i 

s 


LABTAB 

Eig. 7.4 I 

1 ■ I 

If there were blocks surrounding BEGIN in which a reference I 

■ 

to the label II had already been made then the list of equivalent e 

\ 

label counts would extend beyond to, say, so on. | 
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in ow context, is the size required. Seccond is the difficulty 

table 

in pruning the entires from the/when blocks are closed. Considering 
that most references in a block mil be to the entires in itself or 
in a few surro landing blocks, hashing probably will not be so much of 
an advantage, keeping in mind the overheads in hashing. 

7.1.3. Description of the Symbol ’Mble Organization in MIIliFIPl 
Compiler ; 

We have outlined the scheme of symbol table management in 
MINIPl compiler already. We shall now give the details of symbol 
table lookup, attributes and their entering etc. Processing of 
declarations will also be described in short. In important thing 
which complicatesmatters is handling of labels (and equivalently, 
procedvire nmes etc.). This and the modifications requiired by it 
will be taken up in the next section. 

Symbol Table and its Search s 

fhe . argiaa^t column far our symbol table is an array SYMTA1 
with the pointer ISm pointing to the first empty entry in SIMTA1 
(initially, 1 ). An identifier is stored as shorn in fig. 7.1. 

The only difference is that first word pointed to in the string 
space (IDAEEA) contains the number of characters (and not words - 
which have six characters packed in them, with trailing blohks 
appended to fill the last word). 

The routine SRCHM does the job of both searching the symbol table a 
as 

well/ entering attributes. With the argument IWHICH=1 , it searches the 
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symbol table between the limits LOW & HIGH. Ihe identifier is 
assumed to reside in a table IDTABI (necessity of which arises from 
the fact that more than one identifiers, which have not yet been 
looked up in symbol table, may at times remain in the syntax 

tree simultaneously), with ISTiET .pointing to the first entry. 

Search is simple and goes, after checking for equality of the length 
of entry in symbol table and of the identifier supplied, to compare 
the entries linearly from HI(H to LOW. Bor processing a declaration 
LOW is set to IBLPTE, pointer of current block into SYMIM1 , and HIGH 
set to LSYM - 1 . Bor looking up a non-declarative occurrance of an 
identifier LOW is set to 1 . If the search is successful, Index is 
set to the position of the matching entry, if unsuccessful, to 0. 

Bor IWHICH=2, SECHM enters the identifier in LDIIABL at the 
bottom of the symbol table (LSYM). Ihe mechanism of entering is 
just the : ;reverse of accessing IDAEM for a comparision. 

: ^tqr@ the infqpitatipn declared in the form of declaration 

stmt • of MOTHL it is not required to reset the IBLTOZR to point 
to the beginning in symbol tahl© ;^ block A (fig. 7.2) after the 
block B is closed. This becomes necessary however \i\h,en lakels are 
to be handled. Her this purpose IBLPTE is saved on a stack SYMSTK. 

In fact it is one of a set of stacks, called collectively as 
secondary stacks (common area SECSTK) ,to store information about blocks . 
At the end of a block IBLPTE can be restored from the stack. 
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BEG-IK ; AaV 

begin ; /*B*/ 

END ; /*B*/ 

END * ; AA*/ 

fig. 7.2 

It is suggested (17) that the symbol table contain in the 
vexy beginnlng^ll the system functions. Bxis scheme however is 
not envisazed for MINIDI as function - procedures are not a part 
of it. System' functions, which are necessary however, (like /IDDS 
for pointer variables) be classed as an operator SISIN. 

"tributes sud 1jb.6i.r Ha xKiling • 

Iresently the attributes that an identifier can hare been 
divided into eight classes (section 7.1.l), Ibe classes and their 


contents are,,; 


A ;y', A, 


A; , : Basie type (fixed/float/char/bit/label/procedure name 

ItlllA 


jy (.staticAxtemal/dynamicAemporary ) 


A!ER(3)' 

' ' ■ ■ names , whether or not the 

defihtitdLpay.;'B^S^Mbfe-'®ade ) 


atr{a) 

: Procedure count 


ATR(5) 

: Depth of procedure nesting 


AIE(6 ) 

; Empty (as yet) 


A!I!R(7) 

: Offset from respective data area bases 


AER(8) 

; Pointer to bounds area (for arrays) 
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Ihe information content is not of direct relevance here ; 
it is to be used in the semantic processing of individual 
syntactic entities and is relevant there. The attributes are 
stored in two words (in arrays SYEtfT12 and SY1ITA5 respectively) 
for each entry in SYMTA1. first six attributes are stored in 
SYMTA2 and last two in SYMTA3. Routines GETATR & JUTATR fetch 
and store the attribute specified in RATE at the position (in 
SYMTA2 or SYMTAS ) UADE. 

Processing of Declarations : 

Here we shall just summarize the processing of declarations 
in short, the details can be easily gleaned from the program 
listings. Stznctures are not yet catered for, and a message 
saying so is printed for structural declarations. first task is 
to check for proper positioning of declare statements. This is 
done by checking, for all the declaration syntactic entities with 
DBCIiARB as the, first element on the R.H. S., whether an executable 
statement or prooedure de'finition has occurred so far. If yes, 
then call EEffiOR. Even thot^ execution will be deleted, the 

declaration entries are made in th# ‘Symbol table and program compiled 
to point out further errors. 

A pointer IPEPTR is set in the symbol table when the first 
identifier of a declare list is to be entered in SIMTA1. Another 
pointer lERPTR keeps incremoiting for each further entry entered 
in SYMTA1 . Routine SRCHM is called first for a look up. If 
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the index is nonzero, error message for multiple definition is 
printed. But in both the cases(for zero and nonzero index)the 
identifier is entered. Hius in case of multiple definition, the 
last definition is the one that holds for future references. 

Since the factoring is single level only, all the attributes 
but the bound list for array identifiers, appear after the factor 
list is over. These attributes are than entered for all members 
of the factor list, in arrays SYMTa 2 and srMTA3 at addresses from 
IPEBTR to IMPTR. Ihe bound list attributes are stored in 
temporary arrays' TMP1 & TEMP2. TMFI contains the number of 
bounds (or the dimensions), and TEMPa the pointer to the bounds 
area). 

In the above processing, the secondary information ITPP 
(J1XED/T10 AT/STATIC etc.) for the lexial unit is obtained 

from th0 syntax tree TRBEa. An analysis of ITTP is then made to 
sort blit the different attributes- A point to be noted is ; if a 
STATIC comes after EXTiiaiNAI in liie attribute list, it is not stored 
and the storage class remaitia ESTEElAIi, 

7.1.4. labels, Procedure Hame and External Variables ; 

Bae simple pitch of the symbol table organization described 
above is queered some-^hat when we consider the entities mentioned 
in the title of this section. let us teihe the external variables 
first. 

When a variable is declared with attribute EXTMTAL it has 
got to be entered in the current block area in the symtab. However, 
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it has to be linked to its occtirances, if any, in declarations 
in other blocks, and at the end of an external procedure included 
in the header information. Thus the identifiers for the given 
block can not just be deleted from the symbol table as soon as the 
closing EE® is encomtered. One method could be that a separate 
table is kept for external variables for the v\hole procedure. Fow 
whenever, an external variable is declared in a block, it is 
entered in symbol table at the same time it is searched in the 
external-variable-table too. If found, the index is stored in a 
symbol table attribute. If not, it is entered in the table and 
index again stored in the symbol table attribute. All references to 
this identifier now should point to the external variable table. 

At the end of the external procedures this table can become a part 
of the header. 

\ 

label Definition . 

EIFIPl arise at four places (Appendix A.2)i 


<go-to stmt> GO TO; <label> 

<end stmt > <label> .. EKD 

<proc heading> .»■ < label> ., PROCEDUEB 

some variations 

* 

<call stmt> GAIL <idproc> 

some variations 


( 1 ) 

( 2 ) 

( 3 ) 

(4) 


(2) and (3) in fact define the label as an ordinary label 
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(possible target of a GO (DO ) and a procedure name (possible 
target of a CAIl). (l) and (4) are references to labels and 
procedures respectively* 

Although in MINIPl we have precluded the use of variables 
before their declaration,tae same is not true of labels. A label 
may be referenced before it is declared. In fact it is the only 
case possible in MINIPL where GO TO 's are restricted to be used 
like effective exits, by barring any statement other than an END 
to be labelled, Ihe forward references are inevitable because 
procedures can be recinrsively called. Presently we discuss the 
problem with reference to GO TO 's and ordinary label definitions. 
Similar processing is required for CAHi's and procedure definitions 
too . 

It is obvious that a label definition and all references to 
it must be some how linked together. In POETOAlir this can be done 
Comply' the first occurrance of a label in the symbol 

feiole andfmafce it'*dei^ it occurs as a definition and as 

’undefined 'if it ocoin?s' dJQ. a: All the undefined qxxadruples 

are linked togelher and whoa a definition occurs all the previous 
ones are adjusted and the present value of label now used in 
future references. Ihe linking operation does not remain, as 
simple when block structure is taken into account. 

Ihe following example illustrates the problem : 
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BEGIN^ ; 

Xi • ••so* 

GO TO LL ; 

BEGIN^ ; 

GO TO L ; 

GO TO LL ; 

L: 

ENB^I 

1 * 

LL; END 5 

Eig. 7.3 

2 

STow at the time the reference to L is made in BEGIN block 
by a GO TO, we can not know whether to link the L to the definition 
in the outer block or not. 

Ihe method siaggested ( 35 ) is to keep a separate table 

and a separate searching mechanism for labels. All the 

quadruples for GO TO -type of references in an open block are 

linked together in different lists the address of which is in 

the symbol table entry. If a label definition occurrs in the 

referring to it 

block, all the quadruples^can be corrected. If however at the 
end of block the label is not defined yet it has to be passed on 
to the surrounding block and if already there, the 1 ink of 
quadruples referring to the label joined with the ones in the 
present block. 

The situation is no less complicated in MINIPL since although 
the label referred could not have been defined already in 
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the aurrouading block (whose EHD will come after that of the 
present one). Ihe joining of chains problem still exists for 
the statements of the type GO TO LIi(fig. 7.3) and the undefined 
label entires have to be passed to the outer block. Ihis is 
done at the time an EITI) statement closing the current block is 
recognized. Instead of the simple popping of the symbol a 
routine ADJUST is called. This routine looks for all the 
undefined label entires, starting at IBIPTR (the pointer to 
SYMTA1 where the entires for the current block begin), and appends 
them to the preyious block, if a reference does not exist there 
already. 

An important point to maition is that giving the quadruple 
counter (if one is used to aount fche quadruples generated) 
setting as the value to a label, when it is defined, is considered 
meaningless, for. the following reason. Since different qmdruples 
will translate to different number of machine code instructions, 
quadruple count can not be; .of much use to the q-uadruple processor; 
it will have to do the linking, any way, unless a table is used giving the 
number of machine instructions to be generated for each quadruple - 
a rather unwieldly method. 

In the proposed solution, first time a ’GO Tl liL’ type 

-[ 

of reference occurrs in a block like BEGUr (fig. 7.3) an 
entry is made in a separate table as well as the symbol table. 

A counter LiiBCUT is increased by 1 and its value (say nl) stored 
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At the end of an external procedures all the imdefined labels 
will be left in the symbol table, [Che processing for procedure 
names and OALL'b is similar and the undefined procedure names referred 
to in GALI^s will be left in the symbol table. These are obviously 
calls to external procedures. This will also became a part of the 
header information. 

At the time a definition for LI occurrs, quadruples defining 

Ug, n^ are issued and entry MT deleted. Chaining of operands 

quadruple processor will have to be done ary way as actual machine 
instruction values of quadruple will became clear only after pmcessing 
is over up to the defining quadruple. However using the counts 
(n1 etc. ) as an index in a table the need for searching in’ quadruple 
processor is eliminated. 

7.2. Storage Allocation ; 

In MIHIPL there are two classes of storage, STATIC and AUTOMATIC; 
the class of BASED storage, is not included at present but would be 
required for provision of list processing facility described in the 
specifications of MIUIPL (section 3:.4.4). 

7.2.1. Yfaen to Allocate Storage ; 

Before the final machine code is generated, run time addresses 
to variables must be assigned. Where to make this assignment is a 
major design decision. All the references in quadruples could have 
pointed to appropriate symbol table entries. This would delegate 
the task of storage allocation to the quadruple processor. Primarily 
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because this is in conflict with our aim that quadruple processor 
should be as simple as possible it has been decided to perfoim 
this furiction at compile-time. itself (of course, external variables 
can not be allocated storage at compile time, basic entity for 
compilation being an external procedvire. !Ehis is discussed towards 
the end of section 7«2). inother side advantage of performing 
storage allocation at compile time is the saving in the space-time 
product i'osulting from keeping the symbol table in core, only at 
compile time. She disadvantage is that storage allocation is 
machine dependent to a certain extent, but this advantage, can be 
made less weightly by putting all storage allocation work in a 
separate routine (aIDCAT for the present system) and modify it, if- 
necessary, when moving the compiler to a different machine. 

7.2.2. Storage Allocation: Static. Ijyanmic and Pseudo -Ijynamic 

. Static , storage can be allocated to the variable so declared, 

ih an area for the, wSqole . external procedure? of course, scope of 

the particular variables is determftied by the block structure, !I3ae 

AUODIAAIIC storage class is applicable to'.' the , non-static variables 

in various procedure and begin blocks. Although storage of Idaese 

can be allocated statically (Pl/I definition says that variables 

of a block or procedure may not have the same values between 
then 

invocations, but/it is not required to destroy the values), we can 
effect a saving in storage by allocating storage dynamically. Ehe 
dynamic allocation is, anyhow, a must for recuirsive procedures. 
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In the present implementation compiler allocates storage 
dynamically for procedures. This includes obtaining the offset 
of variables from the base of the data area, which is allocated 
at run time on a stack and the size of which calculated at compile 
time. Ibr begin-b locks a pseudo -dynamic scheme is adopted as the 
addressing (at run time) in the dynamic data area is considerably 
more cumbersome than addressiiJg in the static area. The scheme 
involves considering the rtm time data-area as a stack for block- 
jHbwever the allocation ±br blocks is not made at run 
tine. Instead, at the compile time itself a pointer pointing to 
the top of the storage allocated so far (within the procediire data 
area) is decremented v±ien a block is closed by the amomt of 
storage allocated to this just-closed block. Scheme will be clear 
from the example given below s 


A1 t^OCSrOBB ; 
A2iIB0GlD0EE' | 

Bsois^ . .mnr- 

. ..ETO; 

• EHE”, 

begin"'’*, ... END; 
END ; 


Data area for 
procedure A2J 


Storage for 
BB3IN3 


Storage for^;* 
BEGINU I 




— s; 




y 

Storage 




for o 
BSGrlir 


1 

>. storage 

"Tor BBGHiP- 


i 



END; 


ilg. 7.5 
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ilhus parallel blocks can be allocated storage one over the other. 

7*2. 3. Ihe Present Algorlthia ; 

Dae storage allocation is done by the routine AIDCAT, which 
is called when ever storage is to be allocated to a variable. 

Before calling»the attributes of the variables are accessed from the 
syTiibol table and put in the array ATR. Routine AIDCAT basically 
maintains two pointers ST0 E(i) and ST0E(2)>for dynamic and static 
storage allocated so far. Whenever a call is made to allocate a 
variable storage in static area, ST0 r( 2) is incremented by the 
amount of locations needed for the variable in question (a refinement 
will be given in next sub-section). Bor dynamic allocation same 
is done to S!IDR(1). The difference however is in adjustment of 
ST0 R(i) and ST0E(2) in the routine SEMM. SK)R(2) is vintouched in 
the vdaole external procedure and gives the total static ai^a needed 
foi^ the external procedure. STOE(i) on the other hand is treated as 
follows* ' ■ , 

a. Bor every block beginlng (BEGIHj ) the value of the ; 

ST0R(i) is saved oh -a seeonda:pr stack STOESK (done ; 

in loutine SAVEES). ■ ; 

b. Bor eveiy procedure heading the "value is saved as in | 

(a). The ST0R(1 ) now is set to 0, 

; 

c. When the block is ended, the secondary stack ^is , 

popped and the ST0R(1 ) restored. ; 

d. Restoring is done as in c , but prior to that "the ST0 E(i ) i 

value (total size of data-area required by the procediore) ; 



is set as the initial value of a system generated 
variable (g. proc count), which is used for rxin time 
allocation (section 7*3 )• In proc count is the 
lexicographic count of the procedure, i.e, the order 
in which it was opened, and is associated with the 
procedure entry through a third secondaiy stack (lABBIK). 

What all gets Allocated in a Data Area : 

Ib implement the addressing mechanism (section 7.3) and the 
procedure linkage i.e. information and control flow between procedures 
certain addresses are to be allocated in the data area. All this 
is taken care of by calling AlOCAT at appropriate places (i.e., while 
processing the procedure headings and GAlL's etc.). Of course, 
alocate is called when processing declarations to allocate storage 
for different variables. 

. aefineaents in AIDCAl ; 

'ffiough the .'h of the storage allocation is served 

by the description given abdve. Some refinements were made in AIDCAI 

to take care of another problem, ,Ih laany machines, alighment of 

- , - ' requir-.-'.:. 

variables on certain bouindaries (e.g. byte, half ward, full word etc.) is /_ 
With the previous mechanism , the storage allocator AIDGAI would pad 
the previous value to bring the new address at the proper boundaiy. 

This will cause a lot of wastage as the variables coiiLd come in an 
arbitraiy order. Gries (17) has suggested that addresses should 
be assigned first to all words which require alignment on say a 
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doublo word bounclaiy thea to the ones requires say a word boundary, 

half word boundary & so on. Ihe scheme is possible in MINIP'L where 

all declarations come before executable statements. However, the 

inplenentation becomes clumsy as many counters are to be maintained 

in symbol table 

(and their values stored/tenporarily ), then at the end of declarations 
all equivalent addresses in data area calculated (and the counts in 
symbol table attributes replaced appropriately), dhe method, that 
has been incorporated in AIOOAT, to attack the problem is 
as follows (given only for STOE representing both STOE(i) and 
STOR(2) processing for which is identical). 


STOR is set initially to l-IdAXHHT vdaere MAXOTT is the naxinun 
no of the smallest addressable units (e.g. byte for the lEM 3r,0 ) require 
for the largest TYffi (floating pt. in ovir case). Ibr each 1ype 
there is a counter which indicates the position within the MAXDIHC 
ceil' for that type. When a call for allocation is made, the 
pbsitiqrt '^'ip.ter is incremented by the no Of units required for the 




calculated. If "the MAXHUir cell 
is full, 'a ‘new ceil is allocated by increasing SIDE and 




position coinater set' to b^gining of it. 


Ihe method given above assumes that all boundaries fall on 
the MAXURT boundary. If it is not so , the least common multiple 
of all the vrord' boundaries will have to replace MAXOTf above, Althou^ 
the above method is no advantage to the IBM 7044 implementation 
(where the smallest, and also the largest, unit is word) it was 
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written to cater for the byte organized machines,’ Ihe parameteri- 
zation of the routine was attempted to make it machine independent 
but soon it was realized that to pack data into ■t±ie smallest 
addressable unit, will require a rather complex routine and such 
lucdifications are best (most efficiently) incorporated for the 
individual hest computer. 

Initialisation : 

So far the allocation mechanism just allocated the storage 
to variables for run time. The information available was the 
length of data-areas and it was sufficient. However, to allow 
initialisation of variables, additional woik is needed. One method is to 
■generate assignment statements for the initial statements which 
are executed at the begining of run time. Another method and the 
one envisaged here is to prepare a table of initial: values and the 
corresponding addresses and use the quadruple processor to generate 
'dai;a definition machine instructions. In addition to the initia- 
lised variable, liie abova scheme is hecessayy at times to put infooc- 
mation needed at the time of generating’ a quadruple (isay the' size 
of data area, needed for the GE3EEA qifedrdpI'S ■ (sec. '7»3 X) Qhd ' ■ 
becomes available only later (the size of the data area becomes 
known only at the end of a procedure). 

7,2.4 Storage Allocation and the Quadruple Processor ^ 

Ihe information, in addition to the quadruples generated, 
supplied to the quadruple processor will be, 
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a. (Qae table of external references procedures and Tariables. 

b. Tiio table of the initialization values (this will include 
the sizes of the procedure data areas etc. too). 

Iho operands of the ctuadrup'le processor'contain for dynamic 
area variables, the piocedure level no. (section 7.3) and the offset 
within the procedure. ibr these the quadruple processor has to 
generate machine instructions to access them (section 7.3). -Ibr 
other types of storage the first subfield of an operand field contains 
the indication of the type of information to follow in the second 
subfield (details of the quadruple foimat are given in Chapter 7 
(part 2)). The second field will contain the offset in the 
static area, position in the external table and pointer to the label 
table etc. 

Use of IBMAP (the MAI assembler on IHd 7044) was envisayed 
to ip^cess quadruples for the present implementation (section 4*6. 5). 

In addition 'fo tije’ avskwardness pointed out in section 4.6.3, the 
MAI assembler (repres^tatlve of most conventional assemblers for 
processing assembly lah^sges wMch' are. ' intended for programming 
work too) is avdcward to take advantagesifb^l'.'fhe ia:*bees8ilig;done in . 
compiler phase. As will be seen in section 7.3 an offset n1 in 
static area is to be translated as S.nl , thus repeating the symbol 
table formation and storage allocation. Similarly, while a special 
purpose quadruple processor would build the initialization values 
in the static ai^a, at present we will have to issue define instructions 



167 


at the tond. Presently, an instruction to reserve storage for the 
static area for the particular program is issued , vihile the 
special quadruple processor could place this information in the 
header of the external proced'ure. This would have made possible, 
for a linking loader, if it had the capability to do so, to put 
the static storage of all the procedures together, thereby separating 
the program area from the datei area totally. As for the construction 
of the header it was already over as the operands referenceing 
external variables and procedures could have pointed to the header 
table (a). To use map, references by name have to be generated and 
at the end of compilation, for all the entries of table (a), 

SKTEEdl Instructions generated. 

7 .5 . Addressing Mechanism and Run Time Storage Administration . 

The detailed format of quadruples has been discussed in 
Chapter 7 C ifl) , and the addressing for static and external 
v^d^le©' a^eady explained. Examples of both can be seen from 
the Addfix macaxi (Apperyiix E ) whet?e the operand subfield 1 
indicates external variable (lOo). and static variable (101). 

Presently we shall discuss the 'addressing fen', ^ 

7.5.1. Addressing in Ijynamic Area ? 

In MINIIL any procedure can contain a nonlocal reference 
to a variable dec-lared in a surrounding procedure (and not 
declared in the procedure in question. Though the (lexicographic - 
count, offset) pair defines a variables completely. The present 
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mechanism makes use of the depth of nesting (tiie level) of the 
procedure as the first component of the subfield pair for a 
dynaiaic area operand. Ohis hierarchy number ( level) can be used 
as the procedures which have the same hierarchy number are in 
parallel blocks, therefore the compiler never processes them at the 
same time. Iriraarily the effective address of a dynamic variable 
(k,i) can be obtained by adding to base address of the data-area 
for procedure at level k , the offset i. 

7.3,2. Run Kme Storage /uMinistration : 

Ihe first executable quadruple to be produced for a procedure ^ 

■ heading is GEIREA, ^. I , , .G-.Rroc count, where I is the level of the ; 

0 $ 1 of~2 

procedure and G. Proc count described in initialization sub-section j, 

of section 7.3. This quadruple is written as a macro, which is |' 

E 

executed when a procedure is invoked. Ihe macro alocates storage 
. - i tb. fr, B:oc count in a stack (Appendix E ) BOIACK. A gloabal 

f Ihcsation '-SIKTOP contains ,the top of the stack above which a new j; 

allocation Is made. Qh,© base address of the procedure data area 
±a placed in index register 1* How a reference to a variable in 
the currently active' procedure could be done iising iiad^lng ' j 

facility of IBM 7044, e.g. , 

OPCODE OEPSEljl 

Ibr fnis. purpose the reference within the procedure are indicated 

by a special first component (=102) of the operand subfield-palr. ; 
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To mcikG references out side the procedure (to surrounding 
procedures), the base addresses of the referrable procedures are 
copied from the calling procedure data area, in the first few 
locations of the data-area allocated. 

Two cast® arise (fig. 7.6 )j 

o 

Ptoc a 
Sroc -B 

GALI G - (l) 

ProG G : 

Proc D ;■ 

f 

GALL B - (2) ! 

I 

I 

[ 

Ihg. 7.6 I 

jjd tibe/fPrst j ^ inyoking C-(t)) both the I 

' , \ 

i. Then both can refex* to - t 

the 'Thus GEH&A jupt need, copy | 

the first i locations into the^new'data--aren- | 

In the seconcT case (e*g*, D invofciXLg B (2))>: ^ called | 

- : ■ ' : , ' f 

procedure has level lower than the calling, pxbcedw^ [ 

declared in the surrounding block. Again both the procedures | 

can refer to procedures at level 0j1 y • • • •* yi*"1 • In addition^ | 

the calling procedure can . refer to some more proc edin?e«, but that 
is immaterial* Again j we copy the first i locations from the data area | 
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of the calling procedvire into the new data area. The base address 
of the new data area is plugged in (i+1 )th location. 

The whole process starts by executing in the main procedure 
the macro SETREA, instead of GETEEA (Appendix E ), SETREA allocates 
storage to main procedure and copies its own address in the first 
location ((i+l)th locn, where i = O). 

Before exiting from the procedxnrej macro iMRE/l is executed. 
This returns the data area to the run time stack and adjusts 
STKTDP etc. The macros may include instruction for saving return 
address and executing the return from procedure (as for the macros 
given in Appendix ?). These may also include the handling of 
information flow throxjgh formal parameters. 

7.5.3. Addressing and Instruction Set of IM 7044 t 

Let us look at the sample instructions generated (Appendix e) 
for the oper^d part for a dynamic area reference (k^i) where k 
• indicate the level of a surrounding procedure. 


instructions a 

re''-'of the 

form, 

(1 ) 

STO 

admSp 

(Save accumulater into a temporary 

locatioh) 

(2) 

CIul 

k,l 

(load the base address of the procedure 

at level k into the accumulater) 

(3) 

PAG 

,2 

(Put the best address in index 


register 2 ) 



(4) 

(5) 
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01' ■ i,2 • (access dynanic area) 

OLA ADTSVIP (restere the accumulator from th^ 

temporary location) 

The above shows the v/eakness of an instruction set vshich was not 
designed for dynamic addressing. The use of accumifLator and 
associated over head (instr* (l) and instr. (5))? to load the 


base address into register two cones because Ihere is no concept 
base registers in IBM 7044. We are using index registers as bas^ 
registers (which is a crime, any way, as it comes in the way of 
efficient use of' index registers for indexing (unless the sare-rei^-tepe 
is kept track of \ihich is an over head by itself). There is an 
instruction (lAO) for loading an index register from storage but 
this the source address can not be indexed itself. 


Ml' 


If we do not wish to use index registers the following set^ I 

i 

of instructions could be generated; [ 

v"a) Only index register (l) vised for always holding the current f 

' ■' ’ '' l’' ' I 

data area base address. 


(1) 

STO 


(2) 

CIA 


(3) 

ilDD 

= i 

(4) 

STA 

IHDADR 

(5) 

OP* 

IIIBADR 

(6) 

CLil 

ADTEMP 


I 
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How the temporaiy location lEDhDR is used for addressing 
(the instruction 3}4j5 have changed). The niJiaber of instiuctions 
remains the same ^ but, one memojty reference has increased 
(instr. ( 5 )). 

b) Index register 1 also not used. A global location AOIEEa 
holds the current base addr. 


(1) 

SK) 

ADTEHP 

(2) 

OLA 

ACTREA 

( 3 ) 

ADD 

= i 

(4) 

STA 

HTOADR 

(5) 

01* 

lEDARR 

(6) 

OLA 

ADTEMP . 


The last scherae seems best as it avoids using index registers 
completely and is not significantly worse than the first. However, 
the reference to the same area will also now take (6) instructions 
instead of one, 

OP k,1 

Thus among the three the first scheme, also used in the macro in 

Appendix P , seems the most satisfactory. 

7.4 Conclusions : 

In this section we described various aspects of the three 
areas mentioned in the title of the section. Hot everything has 
been implemented. In particular, the quadruple generation for , 
different semantic routines is not implemented, (i.e. label 
definitions generator of area management macros etc. The basic 
organization^ however^ has been implemented. 
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DISCUSSION 


Looking back at our work, with the benefit of hindsight 
wo now have j soiae observations about the project can be made. 

Considering the language design part, we observe that 
the approach has been mostly aupirical. It is based upon the 
important ideas and observations about the psychology of 
programfliing. Although some of the ideas about program structure 
are less vague, yet there is a considerable amount of difference 
of opinion. Moreover, it is difficult to say conclusively, how 
good a match MINIPLis with the needs outlined earlier, Ihe 
problem of simulating the desired constructs and the nonavaila- 
bility of case are irritants which have been tolerated to 
quickly get to a workable language. ^ adopting the format 
of TI/I, compatibility was achieved with a fairly wide spread 
and well supported existing language, which if a definite 
advantage. Only usage of the language, if it.is ful^ imple- 
mented, can say how well It meets the needs of the users.,, 
However, the identification of vthe criteria for picking the 
subset is important by, itself, 

Lhe material in the implementation portion., as a look 
will show, has wide variation in its form and presentation. 


Tht) primaxy reason is the natural variety of infoimatiDn and 
the different levels at which different things can be presented. 

A description of individual routines is desirable and feasible 

when the said routine performs a single task. This however, is 

not always true. Certain basic tasks can be identified but 

their handling is distributed over the whole program. Semantic 

routines are an example. while processing for an MD statement, 

a host of actions related to, say, the symbol table management, 

storage allocation etc., may be taken. The approach has been 

to give more information about a particular basic function. ; 

With the huge amount of information that c^ be needed it may 

be true that documentation is less than complete. However, 

it has been attempted to give the logic by discussing the \ 

I 

problems and the strategies with description of routines just | 

f 

serving to fix ideas. [ 

! 

Another thing. that must be pointed out is that, as far | 

i; 

as implementation description goes,- we have talked about i 

I 

things which are at various stages of completion. The lexical t 

and syntax analysers have been fully implemented.- In addition, 
the overall structure for semantic processing has also been ; 

developed" and implemented. ¥ith this, after getting a general | 

feel of the syntax analysis and general semantic analysis, ; 

it should not be too difficult to extend the semantics to, . | 

include other facilitipa too., Bie basic semantic routines 


like symbol "table managemeii’tj storage alloca"tioii 5 inpu'fc— ou'tput 
and "the generation of quadruplesj have also been implenaated. 
Description of certain things, like label handling, quadruple- 
processing etc.,, details of which were chalked out, have been 
included although their imj-lementation has not been carried 
out. Certain features of MUSfll-'L have not been included, in 
the. running operator grammer, thou^ efforts were made which 
pointed the way to the discussion of pTOblems in using 
transition matrix technique in Chapter 5. 2he resulting 
transition matrix, however', was too large to be used without 
packing more than one element per word. 'itiis is not presently- 
incorporated. 

At times problems arose beca'use the constraint of time 
prevented the desirable separation of design and coding of 
the whole program even though it is agreed that such an approach is beaafic 
ial in the long run when total implementation is the goal. 

Ihe aim of the proj ect was to exqerimeut wA"tJi the 
translation i)TOcess using syntax techniques and mth additional 
constraints of machine independence etc. and it can be said 
that it has been achieved to some extent. Using, transition 
matrix gave insight into the difficulties of making the 
grammar of a real life language suit a particular algorithm.. 
Implementation of seman-fics was indica-tiye of the complexities 
involved. 

Finally, it is hoped that the information about our 
experience in this project will be useful to others undertaking * 
similar projects. 
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1,1 s SYITAX OF MIHIPL 


The Syntax for the lexical units forICCFIPL 
in an easily readable form, is given and folloiyed hy the 
syntax of the MHIPL language, the lexical units forming 
its terminal. 

The syntax notations used are as follows; 

1 . Braces {} are used to denote grouping. 1 vertical 
stroke is used to indicate that a choice is to he 
made . 

e.g. {PIXEID PLOiT} 

indicates the occuranoe of either PIXBI) or PLOIT. 

{ }* is used to indicate that the group may occur 
once, more than once, or not at all { indicates 

at least one ocourance of the group. 

2. Square "bracket [ ] denote options, inything enclosed 

in "brackets may appear once or may not appear at all. 

3 . ' The symbols for lexical units appear in bold type. 

Basic elements of lexical units ; 

letter IBCDEPGHI JKLMKO FQESTTJ"VWXY Z 

digit 0123456789 

quote ' 

others .() 



The lexical ^^nits ■: 


identifier I, ID) letter {letter j digit} * 

integer (IlOUGSR) {digit} 

floating point no. (FLTPT) { { digit }*'' . { di^t > | fiigit F . 

{ digit F"' } B [ +■ I - ] digit [ digit ] 

"boolean constaat (boOLCON) { o|l }B 


Character constant 
(GHiRCOl) 

char string (STBINC) 


delimiters 


' {letter j digit |{ quote qgote)| others}' 
'{letter} digit} {quote quote}] others} 

i 

{letter ] digit j {quote quote}] others}* ' 

{+'-}*l/hi^!» I* KDI^Ij- !•• } 


Ihe MIIUPL Language ; 
Taria"ble , 


af actor 
ai-xim 
arithesqp 
bool prim 
booi lac 
bool eyp 

bool sec 


{ID I ID (arith ejqp' {, arith exp }*) ] 

{ID I ID(arith exp{ , arith erp} *)} . 

{ID I ID( arith exp{ , arith exp}*)} 

{ aprimj af actor ** ap>rim} 

{ INTEGER I BITH! I variable ) (arith exp) } 
{ [+| -] aterm ) arith exp +] - atem } 

{ BOOLCON ] variable ) ( bool exp) } 

{bool sec 113001 fac illD boOl sec }" 
{bool faoj bool exp OR bool fan} 

{bool prim ]N0T bool primlrel exp } 


char prim 

{ CHiRCOSTj Yariable]. 

relational exp 

{arith exp {= 1ne| GT| ¥G| GE] IfflNij lE}axith exp| 

{char prim {=< j¥E }ohar primjbool prim 

{=|IiB|}ohar prim} 

expression 

{arith e3cp|bool exp j char prim } 

return stmt 

EETGEE, . 

begin 

BEGIN 

stop stmt 

sror 

assign stmt 

Tar = exp, . 

end 

{END| IB. . ENB}, . 

call stmt 

Gili ID[ (exp {,.exp} )],. 

proc head 

IB.. PEDCEDTJBE[.(IB {, IB.] )] [EBOTR], . 

get list stmt 

GET HST (Tariable {, Tariable } ), . 

get edit stmt 

GET EBIT (rariable {, Tariable } ) fotnnat, . 

put list stmt 

HIT [BAGeIsEIP [INTEGER]] he ST ((expl STRING > 
{,{ expl STRING }f- . 

put edit stirt 

HJT[PAGe1 SKIP [INTEGER] ]EBIT( {expl STin;NG}{ > 
{exp 1 STRING }f ) fomat, . 

format type 

{{a1x1p|b1} (intbcsr)! b(inieger, integer)! 

SKIP (integer)} 

field 

j[ INTEGER ] format type 

group 

•k 

INTEGER (field {, field }•) 

format 

( {group] field}{ ,{ group] field ) 

attribute 

{PIXSD jPLOAT jBIT ICHAR IeXIEENAL ISTATIC jliSEB 



attrlist 


elem 

elemlist 
decl stmt 


mil 
if stmt 
stmt 

dohe^ 


attrilmte { , attritate}* 

I])[ (INTEGER,. INTEGER{ , INTEGER. .INTSGSR}* )] 
elm { , elec}}* * 

DECLARE {1 elem {, 2 elem attrlist } [ 

{elem jelemlist} attrlist 

* 

{ ,{ elemj elemlist} attrlist } } ,. 

} • 

IF boolexp THEN stmt[ ELSE stmt] 

{ null| getlistj getecTit] patlist[ patedit| stop | 
retam| assignj callj if stmtj group} 

{ D0|D0 var '={ integer j variable) To{integerj 
variable) [BY {integer [variable )] jlX) ISILE 
boolexp ), . 

ic 

{dohead|begin){stmt} end 


group 



A. 2 Operator Grammar for MIwIPL 


1. 

<s-abscr head> 


2. 

•<SLibscr head> 


3. 

<subs var> 


4. 

<strac element> 


5. 

<strac element> 


6 . 

-cstiuc var> 


7. 

<id aiiib> 


8. 

<id> 


9 - 

<id deo • 

->• 

10. 

•dd foxmal> 

->• 

11. 

<Ld proc> 


12. 

<label> 

->• 

13. 

<var> 


14. 

<var> 


15. 

<var> 

-V 

16. 

carith exp> 


17. 

<aritb. exp> 


18. 

^arith exp> 



<id> ( <aritLi exp> 

<saT3scr head> , <arith exp>^ 
<sulDscr head> ) 

<salDs Tar> 

•<:id> 

<stiuc e dement > • <struc element> 
IB 

■<dd aiiib> 

<id ajab> 

<id ambs- 
<id 8imb> 

<id al!i'b> 

<su'bs var> 

<id> 

<strac Tar> 

<arith tem^- 
ADOP <arith teim> 

<arith exp> ADOP <arith tei!m> 


19 . 

<arith teun > 


<arith factor> 


20. 

<arith term > 


<arith term>MIiOP 

<arith factor> 

21. 

<axith faotor> 


<arith prim > 


22. 

Caxitli factor> 


<arith factor> 

<arith prim> 

25. 

<a3?ith prim> 


<int const var> 


24. 

<axith prim> 


FLTPT 


25. 

<arith prim> 

“>■ 

(<arith exp>) 


26. 

<arith prim> 

*>■ 

<var> 


27. 

<int con var> 


INIEGEP 


28. 

<int con var>- 


<var> 


29. 

<Tdoo1 prim> 

-> 

BOOLCON 


50. 

<6001 prim> 

-> 

<Tarial)le > 


31. 

< 1)001 prim> 


(<l)ool exp >) 


ro 

• 

<relation exp> 


OPith exp>. EBIDP 

<axith exp> 

53. 

< relation exp> 


<chsj: prim> EELOP 

<char prim> 

34. 

< relation exp> 


<l)Ool prim> RSIjOP 

<bool priffl> 

35. 

<char prim> 


CHMCON 


56. 

<char prim> 

-V 

<var> 


37. 

<1)00 1 secndry> 


<l)ool prim> 


38 . 

< 1 ) 00 1 secndry> 


NOT <1)0 ol prini> 


39. 

<• 1)0 ol seondry> 

->• 

< relation exp> 


40. 

< 1 ) 00 1 factors 


<bool secndry> 


41. 

<bool factor> 


<1)00 1 factor> MD 

< 1)0 ol secndiy> 

42. 

<l)ool exp > 


<l)ool factor> 


43. 

<l)Ool exp> 


<l)ool e3p> OR <l)ool factor > 



44 


<exp > 


e3cp> 


45. 

<exp>- 

-> 

< 1)0 01 exp>- 


46 . 

<exp> 


<char prim> 


47. 

<call list> 

«- 

GALL <id jiroc > ( <exp> 


48. 

<call list> 


<call list> , <exp> 


49. 

<proc list> 


<labGl> •• PEOC ( <id formal^ 

50. 

<proc list> 


<prac list> , <id formal> 


51. 

<get list stmtj. 

•4* 

GEO? LIST ( <get list> ) 


52. 

<get list> 

4 * 

<vars>' 


53. 

cget list> 

4 - 

<jget list> f <-v8X> 


54. 

<gG-t edit > 

4 - 

GET ESIT ( <gGt list > ) 


55. 

<pat list stmt > 

4 * 

HIT LIST ( <put. list> ) 


56. 

<pat list stmt > 

4 - 

POT < format 1> UST ( < put 

list > ) 

57. 

<pit edit> 

4 

POT <foimat 1 > EDIT ( < put 

list > ) 

58. 

<pat edit> 

4 

HIT EDIT ( <put list >) 


59. 

<get edit stmt> 

4 

get edit ( < format •> ) 


60. 

<put edit stmt> 

4 

<put edit > ( <foimiat > ) 


61 . 

<pit list> 

4 

<exp > 


62. 

<pu.t list> 

4 

STRCON 


63. 

<put list > 

4 

<put list> , <exp> 


64 . 

<pat list > 

4 

<put list> , SOIRCON 


65. 

Kiformat 1 > 


■ PAGE 


66 . 

< format 1 > 

4 

<skip> 


67 . 

< skip > 

4 

SKIP ( IITEGEE ) 


68. 

< skip > 

4 

SEEP 


69. 

<format> 

4 

<grou|) fid > 




< group f ld> 


70 . < format > 

->• 

< format > , < group fld> 

71 . < group f ield> 

->• 

<field type^ 

72 . < group fiGld> 


HrfEGER < field type> 

73 . <group fields 


< integer > ( < format > ) 

74 • < field type>» 

-V 

P ( EJOUGER ) 

75* < field type> 


p (integer , ihteger) 

76 . < field type > 


<sldp> 

77 * <'bound list> 


<‘bound list> ,<oxp> •• < exp > 

78 . <'bound list> 

■4“ 

<exp> •• <oxp> 

79 * <decl stiat> 

->• 

<decl nonstrc stmt > 

80 , <decl stnjt> 


<decl strc sl3nat> 

81. cdecl prfx> 


DECliEE ( <id dec > 

82, <de,ol prfx 1 > 


DECLiRE ( <id dec> (<bound list> 

83 . < decl prfx 1 > 


<decl prfx 1 > , <id dec> 

84 . <deol prfx 1 > 

->■ 

<decl prfx 1>,<id deO (Abound list>/ 

85 • decl prfx 1 >' 

'4* 

<deol nonstrc stmt> , ( <id dec> 

86 . <decl prfx 1 > 


<decl nonstrc stmt> , (<iddec> 

( < bound li 3 t> ) 

87 . < decl non strc stmt > 

■> 

< decl prfx 1 >■ ) ITYEB 

88. ■< docl nonstrc stmt> 

-> 

<decl nonstrc stmt> TYPE 

89, ^decl nonstrc stiiit> 

-> 

<decl prfx 2> TYPE 

90 . <decl prfx 2 > 


PEG LIRE <id dec > 

91 . <decl prfx 2 > 


DECLiSE <dd deO (<bound list>) 

92 , <decl prfx 2> 


<decl nonstrc stmt^ , <id dec> 
(<bound list^) 

93 . < decl prfx 2> 


<decl nonstrc stmtv , <id deo 


94- <deol strc prfx 1 v 

95- <d 0 cl strc prfx 1 >• 


DECLiii® lUGIiGSlR <id dec> 


DECLilEE IF!IIEGER <id deo> (<TDound list>) 

96. <decl strc prfx 2> <dGcl strc prfx 1> , INTEGEEia <id deo 

97. <decl strc prfx 2 > <decl strc prfx 1> , UTIEGEa <id doo 

(<'bouEd. list>) 

98. < deed strc prfx 2 > -v <decl strc stmt> 

99* <decl strc stirit> <;deol prfx 2> !EfEE 


100, <proc hooding> 


<la'bel> . . PBDCSIiURB HIDUE 

101 . < call stints 

-> 

<call list> ) 

102 . < Call stmt > 


C.hIiL <id proo 

IO5. <main proc heading> 


<label> .. PR 0 GED 1 JHE 1 OPTIONS (IvUIIT) 

IC4. <proc heading > 

-V 

< lahe 1 > • • PROCEDURE 

1 05 . < proc heading > 


<proc list> ) 

106 . ^stop stmt> 

-4* 

SID? 

1 Oj , <end stmt > 


ERD 

1 Or . <end stmt> 


•<label>- •• iniD 

109. <go to stmt> 


GO TO <lahel> 

110. <'begin stat> 


ISGIR 

111. <return stmt > 

->• 

RETURN 

112. <oond stmt> 

->• 

IF <1)001 exp> 

113. <if than stnit> 


$ <cond s‘i3iit> THEN 

114. <else stmt> 


f ELSE 

115 <null stmt> 

4 - 

$ , . 

a\ 

• 

A 

0 

V 

4 

DO 

1 17 . <do stmt> 

4 

DO 

118 . «io stmt> 

4 

DO •<iid> RELOP <int con var> TO 


<int con var> 


119 . 

■^do stmt> 

>> 

DO <id> KEDOx-" -cint con 
BY <int con var> 

120. 

<while stmt> 


<do> IflHIIjE ^bcol 6xp > 

121. 

< as sign stmt> 

->• 

<-var> iffiLOP <exp> 

122. 

<stmt> 


a. < get list stmt > , . 

123. 

<stint> 


5 < get edit stint> 

124. 

<stint> 


<put list stmt> 

125. 

<StElt > 


$ <pat edit stmt>- 

126. 

<stmt >• 

-> 

$ <decl stmt^" 

127. 

< stmt > 


? <call stmt > 

128. 

<stmt> 


5 <main proc lieading> 

129. 

<stmt> 


<proc heeding > 

130. 

<stmt > 


0 <stop stmt > 

131. 

<strnt > 


$ c end stmt> 

132. 

<stmt > 


< go to stmt > 

135. 

<stmt >■ 


0 < begin stmt> 

134. 

<stmt> 


C. <retum stmt> 

135. 

<stmt > 


C> <do stmt > 

136. 

■<stmt > 


Q < while stfflt> 

157. 

<stmt > 

<-y. 

■ 0 < assign stmt> 

138. 

<proc hcaiing> 

-> 

<proo list> ) IfflCUD 

139. 

<integer> 

->• 


140, 

■<grotip field> 


•( <foimat> ) 


A. 5 s COSIHG SCHEME FCS IBE GOHSTHIJQTOR 


The input graBimex to the oonstnuctor must "be an 
oporatc^r graaraor expressed in the BHP form and coded in 
nmnhers for non -terminals and terminals to foxm a produc- 
tions matrix, ihe minimum number of columns in the matrix 
must he six. Coding for the non-teiminals should start from 
number 1 onwards. Coding for terminals can be started from 
nny number beyond tie greatest code for non-terminals. Ihe 
number, KTT from which onwards coding for terminals starts 
should be specified alongwith the number of non-terminals, 
KNT, 'he number of terminals KT, the maximum number H, of 
terminals and non-terminals in a production and the total 
number M, of productions in the grammar. 

[Eh.o operator grammar for MINIPh is given in A.2. 
The values of KTT, KHT, KT, K, M and the codes used for 
the non-terminals and terminals are given helow. 

KTT too 
KNT 63 
KT 46 
I 9 

140 


M 


The codes -ascd for the non-terminals of the gramar for 
MINIPl are given helow! 


Code 

Non “terminal 

Code 

I'on-teminal 

1 

< sa'b scr head > 

22 

<pit list> 

2 

< sahs var > 

25 

< formatl > 

5 

< stit element > 

24 

<forme-t > 

4 

A 

•H 

Y 

25 

<grotiX) fid > 

5 

< var > 

26 

<field type > 

6 

<orith exp > 

27 

<deol prfxl > 

7 

< arith term > 

28 

<10™! list > 

R 

<arith factor > 

29 

< dec 1 p.onstrc stmt 

9 

<arith prim > 

30 

<decl prfx 2 > 

10 

<int oon var > 

51 

<decl st2Pprfx1> 

11 

<hool prim > 

CM 

<decl stro prfx 2 > 

12 

-(•relation exp > 

55 

<decl stro stmt > 

15 

>har prim > 

54 

<cond stmt > 

14 

<hool seondry > 

55 

< do > 



56 - 

-get list stmt > 

15 

<hool factor > 


16 

<hool esp > 

. 57 

<get edit stmt > 

17 

< exp > 

58 

<pH.t list stmt > 

18 

<oall list> 

59 

<pat .e.dit stmt > 

19 

<proo list > 

. 40 • 

. <deol staat > 

20 

< label > 

41 

ccall stmt > 


<g©t 3 ±st> , 42 <Bain. proc headin.g> 


21 


Code 

Non "terminal 

43 

<proc heading> 

44 

<stop stmt > 

45 

<end stmt > 

46 

< go to stm t > 

47 

< begin stmt>- 

48 

< return stmt > 

49 

< do stmt > 

50 

< iidii le stmt > 

51 

< assign stmt > 

52 

< stmt> 

55 

< else stmt > 

54 

< null slant > 

55 

< get edit> 

56 

< put edit> 

57 

< struo ■7'ar> 

58 

< skip> 

59 

< iddec > 

60 

< id formal > 

61 

< id proc > 

62 

< idamb> 

65 

< integer > 



The codes used the terminals of the grammar for MHIIPL are 
given helows 


Code 

Terminal 

Code 

xbrnrlnal 

101 

0 

123 

BT 

102 

Ml/LOP 

124 

DEGLIEE 

103 

j 

125 

TYPE 

IC4 

NOT 

126 

STOP 

105 

EEXOP 

127 

BEGIN 

106 

/JD 

128 

GET 

107 

OE « 

129 

HIT 

108 

( 

130 

ID ST 

IC9 

) 

131 

EDIT 

110 

IDOP 

152 

SEEP 

111 

** 

155 

PAGE 

112 

f • 

134 

GAEL 

113 

0 « 

135 

HETHM 

1 14 

P 

136 

PBDGEDIffiE 

115 

END 

137 

OPTIONS 

116 

DO 

138 

MilN 

117 

IP 

139 

STHINGGON 

118 

THEN 

140 

INTEGER 

119 

ELSE 

141 

PLTPT 

120 

WHILE 

142 

GH ARGON 

121 

GO 

143 

BOOLGON 

122 

TO 

■ 144 

ID 



145 

<!> 



146 

EBdUR 


ED2IFIG 

ST^ 

STj'iK2 

NL 

TREE1 

TfiEE2 


TEEE5 


IDTJiBL 

USTiR 

TEiM1 


JIPEBNDIX B 

mSORTMT OOMFI LEE DATA ABEiS jltP Ti^LSS 

n 

This flag is set. while processing a format. 

^ I 

Contains U*s during 3301 tax analysis. 

Contains the range of the future non terminal. 

Is the non -terminal on top of the stak. 

Syntax tree . It contains the relevant teardnals 

& 

' 

and nonterminalsvdiioh fonn the syntax tree. 
Syntax tree. Corresponding to each entry in 
Tree1, there is an entry in TEEE2 which points 
to a table which gives further information about 
the entry (e.g. it will point to an entry in 
the entry in the symbol table if the TEES1 
entry i s a variable) . 

It contains the data type of ihe corresponding 
eletaent in TEEEI, a. zero if ihe element is 
a variable.' 

Identifiers from iiie lexical unit are put in it. 
Structure is similar to that of STEHJG. 
in array, it's nth entry gives the upper range, 
in TEEM1 for search by GETSM corresponding to 
nth 

Contains terminals which may fom pairs with Ibe 
TJ * in who se r ange they lie • 


TEHM2 


U1 


U2 


U3 

ITRA 


IIEM2 


OTJTHJT 


IC 


IC2 


UTffl 


MEMBi 


STE 


HSE'TBL 


It gives the upper range in U1 in which GETSBE 
makes a search to find all corresponding to the 
pair U* T 

It contains U's such that a reduction exists for 
the TJ* T pair and any of IhLese U’s, 

It contains the rule numher of the reduction ■ 
to he performed. 

It contains type of reduction to he performed. 

It is the transition matrix which represents the 
fsa. 

It contains the characters of the lexical unit, 
one character per word in the lowest order hits. 

It is the output matrix corresponding to the 
states of the transition matrix. 

It is the code of the terminal returned hy the 
lexical. 

It is the subcode for the terminal. For example 
if IC indicates that the non-terminal is jaX3P thaa 
IC2 tell whether it is '+' or , 

It is the length of the lexical unit . 

This array i s accessed using ihe internal code 

of the character to get its class, 
is 

Thi s./^ array into vdiich the routine PiCK packs 
the characters of ITEM2. 

It is an array of reserved woris. Some of ihe 
reserved words occuEf "two words of the array. 


STEENG 


INTiBL 


INTBL2 


PLTiBL 


PLTBL 2 


BIIBL2(2) 


CHRTBl 


CHiJe 


ID ABBA 


/ilR 


This array contains the character string 
constants. Bach string constant is preceded 
by a word which contains the number of 
charactejsof the string to a word. 

Table in which fixed point constants are 
entered. 

Allocated address of the fixed point constants 
in IRTiiBL are pat in this table. 

Table into which floating point constants 
are entered. 

Allocated address of the floating point 
constants in FLTABL are pit in this table 
First ontry contains address .assigned to '1'B 
and the second contains the address assigned 
'0* B. 

Table into which character constants are 
entered. 

Allocated address of the character 
constants in CHRTBL are .put in this table. 
Identifiers reside in this table for as long 
as they are required. 

This array is used for passing the attiibutes 
to the symbol tabLe handling routines as 
follows! 

ATR( 1 ) B asic type ( f i xed/ f loat/ char . . . ) 



iffR(2) 

ATR(3) 

ATR(4) 
atr(5) 
ATR(6 ) 
ATR(7 ) 
AIR(8) 

SIMTA1 


SYMTA2 


IP 

LSYM 

SyiSTK 

IBLPTR 

OP 


5 Storage class ( static/ external. . .) 
s Ro. of dimensions if a variable ot,. for labels 
#iether or not the definition Ras been made . 

! Procedure count 
s Depth of procedure nesting, 
s Not used 

s Offset from respective data area bases 
s Pointer to bounds area (for arrays) 

Ihis array is part of the symbol table. Por 
each entry in the symbol table there is a pointer 
in SYMTA1 which points to ihe relevant identifier 
in IDAKEA 

Phis array is also part of the symbol table. It 
contains the first six attributes (as described 
in ATR) of the entiry in packed form. 

It is an array which ccntains the nonteminals 
on the left hand side of each production. 

Pointer to the first empty cell in symbol table. 

Stack for saving IBhPPR 

Pointer of the current block into S1MTA1 . 

An array of opcodes used by quadruple generator. 



APPENDIX 0 


SiMPIE MBriPL SOURCE IHO&EM LISTING 


Source Program Input to the MINIE-L Compiler 


TEST PROCERUEE OPTIONS (MAIN ) , . DECIARE 

A EIXED, B BLOAT, G CHAR, D EIXED, 

GET LIST (A,B,C,D);. 

A = B,. 

IE A = D THEN PUT LIST (G,B),. *ELSE 
A-A/L,. BEGIN,. DECLARE E EIDAT,. 

E**^ . OB’f'3 , • B=^E+B, • 

DO WHILE B NE E, . E = E+1 , . END, . 
B=E^B,. END,. END,. 



Indented lasting Produced by the Compiler 


TEST .. PROCEDURE OPTIONS (MIN),. 

DECLARE A FIXED, B FLOAT, C CHAR, D FIXED, 
GET LIST (a,B-,C,D),. 

A = B, . 

IF A=D THEN 

PUT LIST (C,B),. 

ELSE A = A/D,. 

BEGIN, , 

DECLARE E FIOAT, . 

E^2 . OB+3 , • 

B=E4-B, . 

DO WHILE B NE E, . 

E-E+1 , . 

END,. 

B=E^B, . ■ ■ 

END, . 


APIEIDIX D 


II ST OF ERROR MESSAGES 

1 . WillTIHG FOR MilS/EXTEHEiL EEDGEIiOSE 

2 NESTING TOO DEEP. PEOGTOai TEEMINi^TBli 

5 ELSE BY ITSELF IS lilEMINGIESS 

4 A SWT SHOULD COME BEFORE 'ELSE' 

5 SDPERELD'OUS END 

6 PROCEDURE AT THE IRONG PLiDE 

7 SECOl® PROGRM STiRTS BEFORE THE FIRST ENDED 

8 DECLJEATION SHOULD BE THE FIRST THING IN A BEGIN 
OR PROCEDURE BLOCK 

9 NESTING TOO DEEP. OLD MiRGIN HESUMEll) 

10 THERE SHOULD BE A DELIMITER ON EITHER SIDE OF A 
STRING C0NST4NT 

11 ILLEGAL TERMINAL .... (The terminal is printed here) 

14 SYMBOL TABLE OFERPLOYA JOB TBBMINAEED 

15 ID/iRB A OVERFLOW. JOB TEDMINiiTED 

^ GROUP COUNT MISSING 


ATPMDIX E 


A SMSLE mOGRm EOE QUADRUPIE PROGESSMG 


ADDEIX MACRO 

A1,A2,B1,B2,C1,C2 


lET 

A1=lOO 


GLA 

S.&A2 


lET 

A1=101 


OLA 

A2 


lET 

A1=100 


RUE 

9,0 


lET 

A1=101 


DUE 

7,0 


lET 

A1=102 CHECK 

IE SAME DEETE 

GLA 

A2,1 


lET 

A1=102 


RUE 

3,0 


STO 

ADTME 


GLA 

A1 +1 , 1 


EAC 

,2 


CU 

A2,2 


CU 

ADTEME 


lET 

B1=1 00 


ADD 

S.&B2 


IPT 

B1=101 


ADD 

B2 


IIT 

B1=100 


DUE 

9,0 


lET 

B1 =1 01 


DUE 

7,0 


lET 

B1 =1 02 CHECK 

IE SAME DEETH 

ADD 

B2,1 


lEE 

B1=102 


DUE 

3,0 


SE) 

ADTME 


GLA 

B1+1,1 

- 

lAC 

,2 


ADD 

■ B2,2 


GLA 

ADTME 


lET 

o 

{[ 

o 

o 


STO 

S.&G2 


lET 

C1=101 


STO 

02 


■ lET 

Cl =100 


DUE 

9,0 


lET 

01=101 


DUE 

7,0' 


LET 

01=102 



Dur 3,0 

STO iDmir- 

CM C1+1,1 

PAC ,2 

STO 02,2 

CM ADTEMi- 

EITOM 



ATi’ENDIX P 


STORAGE MMAGEMEIT MCROS 


SETREA MACRO REQMNT 

* THIS MACRO SETS THE DIHAMIC SIACE SDR TEIE MAIF PROCEDDRE 

* INDEX REGISTER IS USED TD HOED THE BASE ADDR. OP CURRENTLY ACTIVE 

* ■ PROCEDURE 

* ALE ADDRESSES IN STACK ARE TRUE ADDRESSES AND IN I.R. ARB COMIL. 


* 

REQMNT 

IS THE DYl'IAMIC AREA REQUIRE MINT POR THE MAIN IROC. 


AXT 

STACK-1 , 1 


tXA 

f ^ 


STA 

STACK PIRST liOGN OP MAIN lEOCEDURE AREA NOW EOINTS 

TO ITS 0?® B0T®DM(0NE BEIDW THE PIRST CELL) 


lAG 

,1 I. REG. 1 NOW POINTS TO STACK BOTTOM 


ADD 

=EEgiINT STKTOP NOEW POINTS TO THE TOP OP STACK 


END! 




lEIREA MAOEO I 

* I IS HiE LEVEL OE THE EOUTINE BEIHG EyTTOn 

* THIS EOUTIITE DOES ALL TBE EXIT KEMALITIES. AEG. EETHBN TO BE INCEUD. 

OLA 1+2,1 

BAG ,4 EETUEE ADDRESS IS IN I.S.4 NOW. 

CIul. 1+3,1 

STA ADTHd' 

I'XA ,1 

DAG ,1 

SXA SIKTOI STKTOI SET TO IEE7I0US( EXITED) IHOCBOIM. 

LAG ADTEt',!r,1 EEGISTET 1 SET TO OLD DROGEDUEE.BASE ADE 

TEA 1 ,4 

ENDM 


GEOSBA MACRO I^REOaRT 

* GB0?REA IS OALIED WHEN ANY lEOOSIURB IS MIIEED 

* I IS THE LEVEE OE THE INVOKED lEOGEDIIRE 

* RECJMNT IS THE DYNAMIC STORE REQUIREMENT OE !IHE INVOKED IROCEDDRE 

* RETURN ADDRESS IS STILL IN I. REG. 4 


* 

* 


LAC 

IXA 

PAG 

I'XA 

STA 

IXA 

lAC 

IXA 

STA 

COPY 

TEIESE 


STKIOI, 

,4 


I.R. 2 POINTS TO TOP OE STACK(iU!roRE BOTTOM) 


1+2 &TH LOCN EROM BOTTOM TO CONTAIN RETURN A 


»4 

1 + 2,2 

,1 

,4 

,4 

1+3,2 BASE ADDR. OE CALLING PROG. IN I+3&TH ICON 
THE FIRST I LOCNS OE PREV DATA lAREA INTO THE NEW ONE. 
ARE THE BASE ADDRESSES OE THE REEERENCABLE PARENTS 


AXT 

COI=Y CLA 
STA 
TXI 
TXI 
TXI 
TXL 
LAC 
CLA 
ADD 
STO 
BNLM 


1,4 

1,1 

1,2 

*+1,1,1 INCREMENT TO POINT TO NEXT lOCN . 
*+1,2,1 INCREMENT TO POINT TO NEXT lOCN. 
*+1,4,1 COUNTER, I.R. 4) INCRTMENTS. • 

COPY, 4, I 
STKTOP, 1 
STKTOP 
=EEQMNT 
STKTOP 


APEEHDIX G 


II ST OF QUiODRUPIES 

A list of quadruples is given. Wtiere necessary a 
comment is given otherwise explaaation is to he found in 
Chapter 7 (Part II ) or is not needed. In the quadruples for 
arithmetic operations P stands for floating point operation 
(as in ADEP) and I for integer operations. In the list, ad1, 
ad2 and ad3 are the addresses of locations, label is a string 
of digits which will he used to refer to a label (e.g. 77 will 
refer to label 3.77)5 a“-d integer gives a directive to the 
quadruple processor. 


ADDP 

ad1, 

ad2, 

ad3 

ADDI 

ad1, 

ad2. 

ad3 

SUSP 

adl, 

ad2, 

ad3 

SUBI 

adl, 

ad2. 

ad3 

DIW 

ad1, 

ad2, 

ad3 

Dm 

ad1, 

ad2. 

ad3 

MD[P 

ad1. 

ad2, 

ad3 

MU 11 

ad1, 

ad2, 

ad3 

OR 

ad1, 

ad2, 

ad3 

aud 

adl, 

ad2. 

ad3 

ROT 

ad1, 

ad2., 

ad3 


EBHNT 

all, 

ad2, 

ad3 

CHRINT 

ad1, 

ad2, 

ad3 

INTCHR 

ad1, 

ad2, 

ad3 

BOURT 

adl, 

ad2. 

ad3 

BOLEEL 

ad1, 

ad2, 

ad3 

BOLCHR 

ad1, 

ad2, 

ad3 

INTBOL 

adl, 

ad2, 

ad3 

RELBOL 

adl, 

ad2, 

ad3 

CHRBOL 

adl, 

ad2, 

ad3 

EELCHR 

ad1. 

ad2, 

ad3 

CHRREL 

ad1. 

ad2, 

ad5 

INTREl 

ad1, 

ad2. 

ad5 

Iff 

adl, 

ad2, 

ad3 

GT 

ad1, 

ad2, 

ad3 

BQ 

ad1, 

ad2, 

ad3 

IB 

ad1, 

ad2, 

ad3 

GE 

ad1, 

ad2. 

ad3 

m 

adl, 

ad2, 

ad3 

m 

ad1, 

ad2, 

ad3 

RL 

ad1. 

ad2. 

ad3 


EEiDIN 

FIIiJD 

MTADE label 

MLSS 

GETliST' aai, aSE 


Convert real to integer 
Convert character to integer 
Convert integer to chacaoter 
Convert bool, to integer 
Convert bool, to real 
Convert bool, to char. 
Convert int. to bool 
Convert real to bool 
Convert char, to bool 
Convert real to char. 

Convert char, to real 
Convert integer to real 


DOIO 


STOR 

ad1 

ENDIO 


GOTO 

label 

BSSS 

integer 

RITEHN 


GUD 

ad1 

PGTLST 

ad1 

FILER 


EROUT 


STRING 


iDR 

adl 

EiGE 


SKCE 

ad1 

PMIRT 

adl 

PTYEE 

integer, ad2 

PTYEE2 

adljadg 

I^-TPHN 


GRPONT 

ad1 

SKEBMT 

ad1 ' 



